点击↑上方↑蓝色“编了个程”关注我~ 这是Yasin的第 56 篇原创文章 程序员大多都有一个共同的经历：当你在改一段复杂的代码时，你一边吐槽……
点击↑上方↑蓝色“编了个程”关注我~
这是Yasin的第 56 篇原创文章
程序员大多都有一个共同的经历：当你在改一段复杂的代码时，你一边吐槽是哪个小可爱写的这段像一坨*一样的代码时，一边打开了提交记录，赫然发现竟然是自己3个月前写的！
明明看起来很简单的业务，但写出来的软件代码为什么会这么复杂呢？这是所有程序员都可能会思考的问题。
“领域驱动设计”号称是一种能够应对软件复杂性的解决方案，它的核心思路是从业务视角出发，去设计软件，并试图把技术复杂性和业务复杂性分离开来。但领域驱动设计是20年前就提出来的，那时候的软件面临的技术挑战和技术复杂性和现在不可同日而语，有些规则可能已经不那么适用。
那软件为什么复杂呢？前段时间看张逸前辈的《解构领域驱动设计》，里面对这块有非常详尽的解释，我觉得他总结得挺好的，这里精炼一下分享给大家：
简单来说，软件复杂是分为两个维度的。从理解能力维度上来说，软件的规模越大，结构越混乱，软件也就越复杂。从预测能力维度来说，软件可能会因为不能很好地适应未来的变化而导致改动成本太大而复杂。
我们可以用一些开发上的概念对应这几个维度，比如规模对应了代码行数和微服务数量；结构对应的是代码的分层设计、服务的调用关系；过度设计指的是为了把软件设计得过分通用，而导致代码设计复杂、可读性降低；设计不足就是很多写死的代码，导致业务变化时会有“改不动”的现象。
那么领域驱动设计的解决方案是什么呢？——通过分解领域，分而治之来「控制规模」；通过合理的架构来「清晰代码结构」；通过抽象合适的领域模型，高内聚低耦合来「应对变化」。
其中，在清晰结构这一部分，我们应该尽量把“业务复杂度”和“技术复杂度”区分开来。比如一个订单业务，业务上关注的是订单的校验，计算订单金