再谈领域驱动设计 _领域驱动设计

本文从需求分析到API设计，试图描述领域驱动设计的过程及思想。同时也能看的出领域驱动设计并不是孤立存在的，它为解决开发团队和业务人员之间沟通而生，进而驱动微服务的划分以及API的设计。

作为一个领域驱动设计的实践者，我切实感受到了领域驱动为软件开发带来的好处，同时在实践领域驱动的过程中也感受到了困难，这种困难体现在工程实践的方方面面，例如什么是领域驱动的最佳设计？如何把书本上的设计灵活的应用在自己的项目上？如何跟团队成员就设计达成一致？
本文尝试从领域驱动设计的目的出发，试图通过简单的描述来说明领域驱动设计的思想。
为什么需要领域驱动设计作为一个软件开发者，多数人以为自己的职责就是编写代码，然而软件开发不是工厂流水线，如果所有的软件开发者不停的开发新功能而不关心设计，那么软件开发过程将会变得越来越复杂，关于这一点大家应该都有不同程度的感受。
【再谈领域驱动设计】软件开发工程师的工作是通过软件来解决问题，编写代码只是其中的一部分工作，设计和交流同样重要。而领域驱动设计就是一个让软件开发工程师交流和共享领域知识的途径。

文章插图

共享领域知识的重要性作为一个问题的解决者，能否理解和认识问题的前因后果至关重要。很明显，如果你只看到了问题的表面，或者对事实有曲解，你显然不会找到一个有效的解决方案。对于开发者，如果你编写的代码只是你的理解，而不是领域专家的理解，你如何保证线上产品的质量？
那么如何保证开发者编写的代码就是领域专家的想法？最简单的办法就是让领域专家来编写代码，但是这种方案可遇不可求，还有没有别的办法呢？
如果领域专家，开发团队以及代码能够共享一个模型，这将有效减少不同利益相关者的沟通及交流，并且会确保所有人都在解决同一个问题。
这个想法要求开发者能够把代码设计为一个反映业务的模型，而这正是领域驱动设计的核心思想。

文章插图

通过业务事件来理解问题域为了在领域专家和开发者之间建立一个共享模型，收集需求并理解业务是第一步。收集需求和理解业务的方式多种多样，而事件风暴经常被用来达到这一目的。业务逻辑可以看做是一系列状态的转换过程，而这些过程转换又被称为领域事件。比如“订单已提交”就是一个领域事件，如果把这个领域事件看做是订单业务的开始，通过梳理”订单已支付”以及”订单已出库”等后续的领域事件，就可以理解整个订单业务。此时对业务的理解被称为“问题域” 。

文章插图

把问题域划分为问题子域通过事件风暴，开发团队和领域专家已经对整个”问题域”有了理解，但是现在着手解决“问题域”还有点早。当我们在面对一个大的问题时，自然而然会想到先将大的问题划分成若干个小问题，然后再考虑各个击破。接下来的一步就是把大的问题域划分为若干个小的问题域。我们有一个网上商城的问题域，能不能把它分割为更小的问题域？
答案肯定的，我们把网上商城的问题分为：“订单”，“销售”，“市场”，“财务”，“采购”等若干个小问题域，再针对小的问题域分而治之。小的问题域在领域驱动设计中被称为“问题子域” 。

文章插图

使用限界上下文创建解决方案理解了问题域并划分为问题子域并不意味着你就能创建出一个好的方案，你无法针对问题子域的所有信息设计出一个解决方案，你的解决方案只会专注于那些有助于解决该问题子域的信息，对于不相关的信息则会人为的屏蔽掉。
为什么叫限界？
在现实世界中，领域的边界很模糊，但是要设计一个好的解决方案，我们需要对问题子域加上一个边界，将不重要的信息排除在边界外。让解决方案专心解决重点问题。
为什么叫上下文？
每个上下文都代表着该解决方案的专业知识。在同一个上下文里，我们共享统一的语言和一致的设计。