能力下沉

一般来说实践DDD有两个过程：

• ★ 套概念阶段：了解了一些DDD的概念， 然后在代码中“使用”Aggregation Root，Bounded Context，Repository等等这些概念。 更进一步，也会使用一定的分层策略。 然而这种做法一般对复杂度的治理并没有多大作用。

• ★ 融会贯通阶段：术语已经不再重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。

大体上而言，我大概是在1.7的阶段，因为有一个问题一直在困扰我， 就是哪些能力应该放在Domain层，是不是按照传统的做法，将所有的业务都收拢到Domain上， 这样做合理吗？说实话，这个问题我一直没有想清楚。

因为在现实业务中，很多的功能都是用例特有的（Use case specific）的， 如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反，这种收拢会导致Domain层的膨胀过厚，不够纯粹，反而会影响复用性和表达能力。

鉴于此，我最近的思考是我们应该采用能力下沉的策略。

所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力 ，也不需要强制要求把所有的业务功能都放到Domain层， 而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉 ，而不需要复用的，就暂时放在App层的Use Case里就好了。

注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程。

通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。

下沉的过程如下图所示，假设两个use case中，我们发现uc1的step3和uc2的step1有类似的功能，我们就可以考虑让其下沉到Domain层，从而增加代码的复用性。

指导下沉有两个关键指标：

复用性

内聚性