根据我个人的领域建模经验，总结了在领域建模过程中遇见的常见问题及对应的解决方案。
问题一
问题描述：业务专家与建模专家之间形成能力的“阻抗不匹配”。
就像对象和关系的“阻抗不匹配”一样，业务专家精通业务，却往往不具备建模能力，而建模专家又往往不熟悉业务（如我，只能泛泛地了解业务知识）。
这就是DDD为何强调领域专家与开发团队工作在一起的主要原因。
解决方案：除了让业务专家和建模专家共同工作，取长补短之外，还有一个办法，就是向企业的业务专家开展领域建模的培训，以提升他们的建模能力；同时，尽可能采用团队成员共同参与的协作化可视化建模，以促进有效沟通，快速反馈，有效形成业务专家与建模专家的合力。
图片
为何事件风暴得到大多数领域专家的认可，并成为一种主流的建模方法？其中一个原因就在于它通过可视化工作坊的形式，为业务专家和建模专家营造了良好的沟通氛围和高效的沟通机制。所谓的“糊墙”游戏，使得参与者可以释放自己，交头接耳，大声讨论，清晰地表达各自的想法。大家协同建模，通过即时贴展现业务流程与事件流，一旦将它们挂在墙上，就很容易发现大家对业务问题理解不一致的地方，通过发现差异统一认识，也起到了传播业务知识的目的。
可视化工作坊的形式可以有效杜绝“闭门造车”的专家建模，即便你不熟悉事件风暴，你也可以采用其他的头脑风暴形式。
问题二
问题描述：在开展领域建模时，缺乏一套行之有效的方法与过程，导致“拍脑袋”建模和随意建模成为常态，无法稳定地输出高质量的领域模型。
解决方案：通过引入DDD方法，建立适合团队的固化建模过程，是成功建模的必要条件。
下图是我总结的服务风暴12步骤，要求团队严格按照它规定的步骤逐步开展建模。
图片
遵循我总计的领域驱动设计统一过程，共分为三个阶段：
- 全局分析阶段
- 架构映射阶段
- 领域建模阶段
每个阶段都有4个步骤，并给出了每个步骤的执行过程与输出结果。前一个步骤的输出结果，又会成为后续步骤的重要输入。
例如，我规定了全局分析阶段的交付物包括业务流程图、业务服务图、业务服务规约和业务架构视图。
图片
图片
图片
图片
架构映射阶段的交付物包括系统上下文图、限界上下文组件图、API契约定义、服务调用时序图和应用架构视图。
图片
图片
图片
图片
图片
领域建模阶段的交付物包括限界上下文的代码模型、静态领域模型和动态领域模型。
图片
图片
图片
问题三
问题描述：面对业务复杂度高，规模庞大的问题空间，难以保证建模的质量，也无法有效控制复杂度。
解决方案：需要遵循“分而治之”的思想，在各个层次开展抽象与分解的工作。
DDD提出的子领域可以有效分解问题空间，限界上下文和聚合在不同层次上完成对解空间的分解，都是建模的重要支点。下图是我总结的DDD各层边界控制的内容。
图片
无论从问题空间到解空间，还是从战略设计推进到战术设计，领域驱动设计一直强调的核心思想，就是对边界的界定与控制。
控制了模型（战略层次和战术层次）的边界后，不仅因为缩小规模而降低了建模的复杂度，还能够在规定好各个单元之间的协作机制后，将它们分配给不同的领域特性团队，确定好职责边界，开展并行建模，如此也可以极大提升建模的效率。
问题四
问题描述：容易出现大而全的领域模型，看起来很美，一旦落地，会发现得到的领域模型存在很大的问题。
解决方案：遵循“迭代建模”的原则。迭代的过程是两个方向不断迭代的过程。
一个方向是在更高层次上追求“广度优先”，把建模工作尽可能覆盖得更广，形成统一而清晰的业务蓝图，包括主要的业务流程、划分子领域、确定子领域与业务服务之间的关系，进而确定限界上下文、定义限界上下文外部的接口，明确限界上下文之间的协作关系。
另一个方向是选择核心子领域追求“深度优先”，深入到这些核心子领域映射的限界上下文内部，编写业务服务规约，迭代地开展领域分析建模和领域设计建模，甚至尝试针对核心主流程对应的限界上下文开展实现建模，输出功能不完整，但具有可用特性的可运行代码。
融合广度优先与深度优先的迭代建模方式，和DDD结合起来，简单来说就是战略设计采用广度优先，战术设计采用深度优先。
这种迭代建模方式需遵循MVP（Minimal Viable Product，最小可用产品）思想。在确定了解空间的限界上下文，可以开展如下图所示的领域建模方式：
图片
遵循MVP思想开展的迭代建模具有两个优势：
- 最小可用的领域模型：每次迭代获得的领域模型都是可运行的，功能可验证的，即在每次小步成功的基础上开展增量式的迭代建模
- 分析设计实现的分离与统一：分析建模、设计建模和实现建模的主导者不同，目标不同，方法不同，却又都是在前者基础上开展的，从而保证了三个步骤的分离与统一，既降低了复杂度，又避免了模型的不一致
我特别害怕企业搞轰轰烈烈的“建模运动”，从上到下打鸡血，定任务，高呼“奋战30天，多快好省地打造企业级领域模型”，然后，集中核心成员加班加点完成一个貌似完整详细、巨细无靡、规模庞大的超级领域模型，却没有产出哪怕一行可以工作的代码。在得到这么一个超级领域模型之后，企业又召集许多业务专家和建模专家对它进行几天封闭式的模型评审。这一做法虽然利用了团队的力量，做了充分的沟通和协作，但和“闭门造车”的专家建模一样，缺乏及时反馈与快速验证，得到的大而全的领域模型很有可能只是一个看起来很美的空中楼阁。
