Real World 是由 thinkster 这样一个在线编程教育机构发起的一个前后端分离的项目规范。用以展示并作为教材教大家用 react、angular 等不同的前端框架或者 rails、django、spring boot 等不同的后端框架实现同一个项目时的实践是什么样子的。我觉得这个主意非常的好，它让大家对技术的讨论有了一个共同的主题，在采用不同的技术栈以及设计思路解决这个共同的问题的时候我们可以更确切的看到不同的方案之间的优劣，从而更切实的（而不是零散的代码和想象）了解不同框架、语言、设计思路在实现一个项目时的差异，从而帮助我们更好的选择项目的解决方案。当然，从单个技术栈来看，它提供了一个做出完整项目需要都需要哪些具体的知识点，可以当做某一个技术栈的入门小项目来学习和借鉴。
虽然这个项目叫做 real world，相比 todomvc 这样的 hello world 确实复杂了不少，但是很显然它的复杂度还仅仅是一个人几个小时就能完成的水平，当然不能全面的反映出一个框架的水平，仅做参考。
本篇对项目做一个整体的介绍，后续会有一些细节的介绍。文章中会涉及到一些 DDD（领域驱动设计） 相关的概念，想要更多的了解建议看看最下面相关材料中的链接。
项目功能
conduit 是 realworld 要实现的一个博客系统。具备一下的功能：
- 用户的注册和登录
- 用户可以发表、编辑文章
- 用户可以对文章添加评论、点赞
- 用户可以关注别的用户，关注的用户的文章会展示在用户的 feed 中
这是一个前后端分离的项目，其提供了后端 api 的规范。这里，我们不评论其 API 设计的好坏，要完全遵循其设计并实现它。当然，对于不同的语言和框架实现都有其 API 设计的偏好，既然这里定死了一种规范，那么在实现的过程中难免会有一些 tricky 的地方需要我们去克服。
目录结构
如标题所述，这里我提供了一个 spring boot + spring mvc + mybatis 的实现。其大概的结构如下:
.
├── JacksonCustomizations.java
├── MyBatisConfig.java
├── RealworldApplication.java
├── api
├── application
├── core
└── infrastructure
-
api是 web 层，实现了和 spring mvc 的 web 接口 -
core是业务层，包含了最关键的业务实体和领域服务以及其各个实体之间的交互 -
application是对外的服务层，由于这个项目本身的业务并不复杂，这里处理的基本都是各种信息的查询 -
core中定义的大量接口在infrastructure包含了其具体的实现，比如 data mapper 的实现，具体的密码加密的实现等 - 其他则是一些整体的配置类，如主类
RealworldApplication数据库配置类MyBatisConfig等
六边形架构
六边形架构 或者说是 洋葱架构 其实不是一个什么新东西，因为分层架构会导致其最底层的实现是数据库，而之前很多的业务逻辑和数据库是揉在一起的（事实上很多项目也确实这样，大量的存储过程中包含着业务的逻辑，业务和数据库紧密的结合在了一起）；但实际上，一个应用最核心的东西应该是业务逻辑，而业务逻辑是不应该和技术细节有强关联的，数据库实现和视图层一样，是某种技术细节，不应该和将其与业务逻辑绑定，所以应该用应该强调内部和外部：内部是我的业务逻辑，而外部与外界沟通的基础设施和技术细节，比如具体的数据库存储，比如 restful 的 api，再比如 html 的视图。
通过这样的思考方式，我们可以认为 mysql 数据库实现仅仅是众多数据库实现中的一个而已，我们可以在不同的环境中轻易的替换掉它，尤其是为对业务的测试提供了可能：我们可以采用内存数据库或者 mock 轻松的实现业务测试。
我所实现的这个 realworld 项目也基本遵循这个架构，首先在 core 中定义了我们的业务实体 User Article 已经各种 Repository 的接口。他们定义了这个项目核心实体的关系以及交互行为。其中具体的 Repository 的实现以及 web 接口的实现都与它无关。对于比较简单的数据创建等行为我们直接在 web 层中处理了，而相对比较麻烦的查询业务我们按照用例在 application 中提供。
在 api 层直接创建用户：
@RequestMapping(path = "/users", method = POST)
public ResponseEntity createUser(@Valid @RequestBody RegisterParam registerParam,
BindingResult bindingResult) {
checkInput(registerParam, bindingResult);
User user = new User(
registerParam.getEmail(),
registerParam.getUsername(),
encryptService.encrypt(registerParam.getPassword()),
"",
defaultImage);
userRepository.save(user);
UserData userData = userQueryService.findById(user.getId()).get();
return ResponseEntity.status(201).body(
userResponse(new UserWithToken(userData,
jwtService.toToken(user))));
}
在 application 层创建一个 findRecentArticles 的服务，用于处理相对比较复杂的查询：
public ArticleDataList findRecentArticles(String tag,
String author,
String favoritedBy,
Page page,
User currentUser) {
List<String> articleIds = articleReadService.queryArticles(tag,
author,
favoritedBy,
page);
int articleCount = articleReadService.countArticle(tag, author, favoritedBy);
if (articleIds.size() == 0) {
return new ArticleDataList(new ArrayList<>(), articleCount);
} else {
List<ArticleData> articles = articleReadService.findArticles(articleIds);
fillExtraInfo(articles, currentUser);
return new ArticleDataList(articles, articleCount);
}
}
注意 这里之所以没有为创建数据的用例在 application 中创建 service 纯粹是因为它们比较简单，在面向复杂的场景时是可以提供的。
CQRS
在 DDD 中 Repository 主要负责数据的持久化：它的任务非常的简单：要么是将内存中的 aggregate 储到数据库中，要么是从数据库中将指定 id 的实体从数据库中重新在内存中构建起来。它实际上是不负责那种复杂的查询业务的，比如获取被喜爱最多的 50 篇文章。更多的内容可以看这篇文章。
CQRS 全称 Command Query Responsibility Segregation，强调一个系统的读模型和写模型是分离的。其中 DDD 所实现的是读模型，保证了业务的实现以及数据的一致性。而读模型则纯粹是利用底层数据库的优势将用户需要的数据拼装起来，完全不涉及到实体。这样的好处在于我们可以完全实现界面所需要的数据模型和真正的业务模型的独立演进，不会因为一个界面上数据展示的变化而导致本身的业务模型出现变更。当然，这里所谓的界面就是我们的 json API 规格。对于查询业务，我们在 application/data 下提供了单独的 Data Transfer Object。
@Data
@NoArgsConstructor
@AllArgsConstructor
public class ArticleData {
private String id;
private String slug;
private String title;
private String description;
private String body;
private boolean favorited;
private int favoritesCount;
private DateTime createdAt;
private DateTime updatedAt;
private List<String> tagList;
@JsonProperty("author")
private ProfileData profileData;
}
可以看到 ArticleData 就是 DTO 或者说是 Presentation Model 它和 API 文档中对数据的格式要求完全对齐而不考虑 Article 和 Author 到底应不应当属于一个聚合。
而下面则是在 core 下的实体：
@Getter
@NoArgsConstructor
@EqualsAndHashCode(of = {"id"})
public class Article {
private String userId;
private String id;
private String slug;
private String title;
private String description;
private String body;
private List<Tag> tags;
private DateTime createdAt;
private DateTime updatedAt;
...
}
很显然，这里 Article 中并不包含 Author 的概念，因为它们并不属于一个聚合，Article 只能保存另外一个聚合的 Id (userId)。
具体的代码见 GitHub 欢迎 star、fork、报 bug、提供 PR。
