一文教会你如何写复杂业务代码( 三 ) 作者|张建飞阿里巴巴高级技术

文章插图
使用这种上下结合的方式，我们就有可能在面对任何复杂的业务场景，都能写出干净整洁、易维护的代码。
能力下沉一般来说实践 DDD 有两个过程：
1. 套概念阶段了解了一些 DDD 的概念，然后在代码中“使用”Aggregation Root ， Bounded Context ， Repository 等等这些概念。更进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。
2. 融会贯通阶段术语已经不再重要，理解 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 层，从而增加代码的复用性。
文章插图
指导下沉有两个关键指标：代码的复用性和内聚性。
复用性是告诉我们 When（什么时候该下沉了），即有重复代码的时候。内聚性是告诉我们 How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为 Domain 层的能力也是有两个层次的，一个是 Domain Service 这是相对比较粗的粒度，另一个是 Domain 的 Model 这个是最细粒度的复用）。
比如，在我们的商品域，经常需要判断一个商品是不是最小单位，是不是中包商品。像这种能力就非常有必要直接挂载在 Model 上。
public class CSPU {private String code;private String baseCode;//省略其它属性/*** 单品是否为最小单位。**/public boolean isMinimumUnit(){return StringUtils.equals(code, baseCode);}/*** 针对中包的特殊处理**/public boolean isMidPackage(){return StringUtils.equals(code, midPackageCode);}}之前，因为老系统中没有领域模型，没有 CSPU 这个实体。你会发现像判断单品是否为最小单位的逻辑是以 StringUtils.equals(code, baseCode) 的形式散落在代码的各个角落。这种代码的可理解性是可想而知的，至少我在第一眼看到这个代码的时候，是完全不知道什么意思。
业务技术要怎么做写到这里，我想顺便回答一下很多业务技术同学的困惑，也是我之前的困惑：即业务技术到底是在做业务，还是做技术？业务技术的技术性体现在哪里？
通过上面的案例，我们可以看到业务所面临的复杂性并不亚于底层技术，要想写好业务代码也不是一件容易的事情。业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。
业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如，如果你需要去开发 Pandora ，你就要对 Classloader 有更加深入的了解才行。
但是，不管是业务技术还是底层技术人员，有一些思维和能力都是共通的。比如，分解问题的能力，抽象思维，结构化思维等等。
文章插图
用我的话说就是：“做不好业务开发的，也做不好技术底层开发，反之亦然。业务开发一点都不简单，只是我们很多人把它做“简单”了