领域驱动 - 开篇

1. 前言

作者在 2019 年入职一家公司，主要负责企业内部 ERP 系统建设。在我入职时该系统已经是一个庞大的单体项目，项目复杂度已经对日常更新迭代造成很大影响。通常我们在一个不了解的业务领域进行功能迭代时会通过产品设计文档、技术方案设计文档、业务代码对整个业务领域功能设计、业务流程设计、技术设计进行充分的了解，然而现状是产品设计文档、技术方案设计文档缺失或者版本很老，开发人员只有通过代码来了解整个业务领域的现状以及一些设计细节。而这个单体项目在开发之初就没有建立很好的代码编写规范以及技术方案设计的指导思想，当一个大厦最初的地基设计不好而后建设团队成员又不断变更给这个大厦建设带来了更多的复杂度，综合因素下就导致我们在了解业务领域细节是需要花大量的时间来阅读代码，而最可怕的是在实际工作中我们在一个需求开发过程中工期是受限的，所以经常就会出现开发人员由于工期受限没有过多的关注代码实现细节（尤其是新人）或者代码复杂度过高忽略了一些看似不起眼但实际做了很重要的业务操作的方法，导致 BUG 率飙升和生产环境事故，而单体项目系统一旦出现问题将对整个系统造成影响。幸运的是在我入职前，团队已意识到该问题正着手对该项目进行拆分和重构，我在其中也承担了一部分工作。而后公司发展了新业务线，我有幸成为该业务线系统建设的主导者，在新业务线系统建设之初我就在考虑怎么避免前车之鉴呢？有没有什么指导思想能帮助我们对问题域进行分解呢？领域驱动正是一个不错的对问题域进行分解的指导思想，在很久之前便看过领域驱动相关的文章，但因各种原因从未进行过实践。新业务线给我带来了实践机会，系统建设初期我便尝试对领域驱动进行落地，通过一些手段让其尽量避免天平向坏味道倾斜。然而领域驱动落地是艰难的，各种文章很多，几乎每个人对领域驱动理解都或多或少的有一些理解差异。所以为了避免落地一个四不像，我在考虑落地方案时便要求自己设计的方案必须要能够解决现实中的实际问题，而不能是教条的为了落地而落地。由此落地过程中也有了一些心得，所以想通过一系列文章将我的一些心得发布出来，为读者们提供一些参考。

2. 阅读条件

本系列文章不会涉及过多的领域驱动概念的讲解，我默认大家都对领域驱动有足够了解，想落地领域驱动但不知道该怎么做。文章偏向工程实践，同时也会涉及领域驱动与一些其他的设计思想的结合，如：微服务、CQRS、事件驱动、事务性发件箱、基于可靠消息的最终一致性方案等。

3. 文章发布策略

因工作原因并不能保证文章的稳定发布，所以我尽可能的利用有限时间把一些比较简单的即便不落地领域驱动也能借鉴的一些工程实践通过文章发布出来，所以文章的发布顺序不会按照从战略设计一直到战术设计的顺序进行发布。

4. 我理解的领域驱动

领域驱动是一个指导思想。战略设计是指导如何对问题域进行分解确定业务边界，而战术设计则是指导如何进行具体的实现。从战略设计到战术设计可以看作是从整体到局部的一个设计过程，而领域驱动却不仅仅是指导如何进行设计，更重要的是统一概念和思想，在系统建设过程中大家思想和认知不能统一是很可怕的，很可能导致目标不一致，理解偏差，这也就是为什么有这么多规范出现的原因。

5. 从组织架构出发落谈谈落地领域驱动的难点

领域驱动其中有一重要角色便是领域专家，而大多数公司没有这个专门的岗位。通常一个面向企业内部使用的软件领域专家由业务方和产品经理共同组成，而面向个人用户的软件领域专家则是产品经理。领域驱动设计统一语言是其中重要的一部分，目的是为了统一概念和思想。然而如果领域驱动仅仅由技术团队独自为战则将变成一个难点，上面我提到领域驱动战略设计最重要的就是对问题域的分解确定业务边界，然而现实中产品设计文档经常出现一个大而全的功能，理由是业务方操作便捷性，如果这样设计很难将问题域进行分解，也就很难落地领域驱动，而系统建设不仅仅是如何实现功能，还需要考虑分布式系统带来的各种挑战以及可拆分、可扩展。在这种情况下通常我的做法是通过领域驱动的知识来帮助产品经理进行问题域分解，说明现有设计的缺陷，在交流过程中带出一些领域驱动的概念，让产品经理意识到领域驱动和问题域分解的重要性。

6. 从开发团队规模出发谈谈落地领域驱动的难点

在很多公司中开发团队总是面临一个很着急的需求以及需求设置有 deadline，一旦有这种情况出现别说什么领域驱动对问题域进行分解了，就是最基本的代码质量可读性、可扩展、可维护性都很难保障。通常我们想要快速实现需求以自己最熟悉的方式进行开发总是最快的，然而领域驱动问题域分解对经验是一个重大考验，如果落地领域驱动最初在战略设计过程中必定要消耗比较长的时间，而这个还没完，通常我们熟悉的开发方式是面向过程的、贫血的，战术设计中对聚合进行建模以及针对充血模型的编码方式的改变都会带来开发时长的增加，当开发团队规模很小就很难在满足需求时间限制的同时落地领域驱动。如果一定要落地，争取时间则变得很重要，但当你无法争取到更多时间时，加班成为唯一解决方案，但这带来的副作用是团队成员稳定性以及成员的工作状态都有极大的影响。同时开发团队如果规模很小，很可能一个人就要负责好几个子域甚至是领域，这对贯彻一些指导思想的执行也会成为一个难点。

7. 从业务规模出发谈谈落地领域驱动的难点

通常系统开发过程不是一次全开发完成所有问题域都已经完整的呈现出来，而是通过不断的迭代来满足业务需求。系统建设过程中通常我们还需要考虑部署成本，而领域驱动中拆分的最小粒度是限界上下文，而当业务规模很小时并不能申请到更多的资源来满足如此细粒度的拆分。但这并不意味着我们在业务发展的初期就不能落地领域驱动，反而在最开始我们就应该关注后续可能的复杂度，很多坏味道就是在最开始只关注如何快速完成需求，想着后续再重构，但实际情况可能是根本没有时间和人力来进行重构，当系统一直处在这样恶性循环下最终都会面临我在前言中提到的问题。这就需要我们进行妥协设计，因此会出现一个服务中出现多个限界上下文，因此我们需要通过一些设计手段来降低后续的拆分难度。