基于领域分析设计的架构规范 - 关于重构与落地

DDD落地之殇

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

1. 规范多，尤其是充血模型，需要对业务有更清晰的认识

2. 代码结构相比无状态扁平化开发，层次深，模块划分更严格，所以，至少从文件数上来说，是更多的（代码行数倒是不一定多）

3. DDD并不是一个“刚性”需求，如果不按这个规范来做，系统一样可以跑起来，所以，很多规范处在一个“模糊”的界定上，让开发人员无法确定到底该如何规划代码。

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

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

所以，我们需要找到一个破冰的办法：

• Leader足够强，团队成员实力不错，也给予Leader充分信任，那么在一开始就采用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 里的方法迁移过来。