(6) 基于领域分析设计的架构规范 - 关于重构

本系列目录：

1. 改变与优势
2. 领域分析基础
3. 读写隔离
4. 充血模型之实体
5. 充血模型之Service
6. 关于重构

不论大家是否认可我在这里提到的这一套小架构，既然你能看到这里，还是由衷表示感谢。

核心内容已经介绍得差不多了，接下来还是看两个很实际得话题。

DDD落地之殇

DDD这类架构真正落地困难，我觉得，有几个原因：

1. 规范多，尤其是充血模型，需要对业务有更清晰的认识
2. 代码结构相比无状态扁平化开发，层次深，模块划分更严格，所以，至少从文件数上来说，是更多的（代码行数倒是不一定多）
3. DDD并不是一个“刚性”需求，如果不按这个规范来做，系统一样可以跑起来，所以，很多规范处在一个“模糊”的界定上，让开发人员无法确定到底该如何规划代码。

正因为如此，即使团队技术Leader了解DDD，却在项目一开始的时候，由于考虑带DDD的代码量相对过多，规范过多，为了快速开发迭代，往往继续沿用最通用的写法。而一旦到了中期，业务复杂度上来了，这个时候觉得领域分析有用武之地的时候，低头一看，系统的复杂度已经到了难以轻松驾驭的程度，更别说来一个180度的大转变了。

真的，这很现实，就是一个恶性循环。

所以，我们需要找到一个破冰的办法，从以下几点思考：

• Leader足够强，团队成员实力不错，也给予Leader充分信任，那么在一开始就采用DDD
• 在一开始依旧采用非DDD架构模式，但利用迭代的方式，将代码逐渐变成DDD

这两者没有绝对好坏，虽说第一种不常见，但依旧是我挺期待和欣赏的做法。

而可能更实用的是第二种，但新的问题又来了，如何逐步迭代改进成DDD，从哪里入手？

现有代码改进DDD

以下给出一个循序渐进的参考方案：

1. 读写隔离

这个过程几乎不与业务挂钩，我们将OrderService,ProductService中的查询方法剥离出来，放在诸如OrderFinder,ProductFinder之中，具体编码细则规范参见之前的章节。 整个过程，一般来说，只要编译能通过，代码就不会有什么问题。

2. 提取Factory

在查询方法被剥离之后，就只剩下增/改/删了，其中增又是最特别的，前面在讲工厂的时候提到过，所以将一个实体的创建行为提取到一个XXXFactory中，也不困难，稍微留意一下，也不容易引发业务问题。特别是在一个已经相对复杂的系统中，如果没法一下子分析透彻聚合根的归属问题，那么可以每一个实体都加一个Factory，之后再逐步合并，虽说工作量稍大一点，但对于已经有点棘手的项目来说，也算是一个快刀斩乱麻的办法。

3. 提取{Action}Service

也就是提取我们前文所提到的，跨多个聚合的一个事务操作 到一个独立的Service中。
或者一个开始，还可以将要求降低一点，只要觉得代码量特别大（我个人觉得150行以上就很大了，何况有些还带了私有方法）的一个方法，迁移到一个独立的Service中，并采用前文提到的{具体操作}+Service的命名方式，一个Service只负责一个复杂的方法。虽说不会非常精确，但重构后的效果还是会很明显的。

4. 建立领域聚合体系

经果上面几步操作，我相信你的代码里，曾经那些OrderService,UserService，已经只剩下相对简单的一些改/删操作了，其实，某种程度上，他们已经逐步出现了领域聚合对象的样子了。所以，如果你做到这一步，暂时停止了，也已经值得庆祝了！

那么如果还要继续前进一步呢？小项目还好，对于大项目，会有些难了。我相信这时候Order，User很有可能是被POJO/DTO存在的，为了保证平滑过度，我们肯定只能新建领域模型，那么可能会要采用诸如OrderDomain来表示了。然后再将之前OrderService里的方法迁移过来。

但如果你用的是Spring或者类似Spring的IOC框架，会有一个很现实的问题。由于实体是被ORM框架new出来的对象，是脱离IOC容器管控的，所以如果你要在一个实体中使用一些IOC容器里的组件，可能得要自己去通过IOC容器的上下文来手动获取，比如通过ApplicationContext来获取，而不能通过@Autowired来自动诸如了。

关于版本迭代

唯一不变的就是变化。

我们经常得要“笑着”对着甲方或老板说：“我们会拥抱变换”，呵呵~ 很苦，但得要面对啊。

所以，假如我们有一个领域实体为订单明细，大家可以很容猜到，它也是属于订单聚合中的一部分，而非聚合根。订单明细的变动，都来源于订单的操作，比如订单编辑，order.modify()。

某一日，产品需求发生变化，说：

• 我们的订单明细要单独展示一个管理页面，而不只是像以前那样，只能从某一个订单点击查看“详情”才能看到
• 同时，我们要能对订单明细进行修改，并且将这些明细的订单绑定关系进行修改

这时，你会很明确的发现，曾经的订单明细已经开始“昂首抬头做主人”了，不再“寄人篱下”了，因为它的查看入口不再附属再其他实体上，而且我们还得精确找到某一个明细进行修改。 独立，修改。

产品既然这样设计，意味着订单明细在整个业务系统中的身份已经发生变化，它的独立性也将越来越强，未来很多功能很有可能将围绕它而展开。所以，订单明细将成为一个独立的聚合，进而我们会做出一些变化：

1. 订单明细将有自己的 OrderDetailFactory
2. 订单明细将逐步建立自己的方法，出现如 orderDetail.modify()
3. 曾经订单聚合中的一些操作，要迁移到新的Service中，因为他们是不同的聚合了，有些操作已经属于跨聚合操作

其中第(3)步，是难度最大的，因为要改动以前的代码，甚至要动到业务，不仅有开发难度，还有测试难度。

但是很遗憾的是，任何重构都是这样的。不论用什么框架，到一定阶段，我们都会面对这个问题。不在开发期间进行优化，那技术债务，只会变成成千上万的BUG来给我们上课。有的时候我们总吐槽自己又拿到的一个前人的项目，说代码多么烂。但是反思下来，现在自己手头的代码，重构过吗？是不是也会成为未来人的笑柄呢？

其实这个未来人可能很近，就是一个月后的你自己。