如何基于DDD构建微服务架构( 二 )

说明：SOLID原则
SingleResponsibilityPrinciple：单一职责原则
OpenClosedPrinciple：开闭原则
LiskovSubstitutionPrinciple：里氏替换原则
InterfaceSegregationPrinciple：接口隔离原则
DependenceInversionPrinciple：依赖倒置原则
领域驱动设计核心要素
如下图所示是领域驱动设计的核心要素，包含领域驱动设计中的通用模型术语和重要的战术模式。这些模式不仅可以捕获和传递领域中的概念、关系及逻辑，也能帮助我们管理业务的复杂性并确保领域模型的行为清晰明确。

文章图片
领域：相对于软件系统来说就是系统要解决的现实问题。
子域：对于领域进行不同维度切分的相对内聚的子系统单元。
分层架构：通过分层架构将业务域和技术逻辑域隔离。
服务：服务通常是领域对象的调用方，用来协调领域对象完成指定业务逻辑职责。
实体：实体与面向对象中的概念类似，它是领域模型的基本元素，在领域模型中，实体应该具有唯一的标识符。
值对象：值对象是没有唯一标识符的实体。值对象在领域模型中是可以被共享的，它们应该是不可变的，当有其他地方需要用到值对象时，可以将它的副本作为参数传递。
聚合：聚合使用边界将内部和外部的对象划分开来。每个聚合有一个根，这个根是一个实体作为外部可以访问的唯一对象。
资源库：是封装的所有获取对象引用所需的逻辑单元。
工厂：工厂用来封装对象创建所必需的信息，当聚合根建立时，所有聚合包含的对象将随之建立。
2
专注问题域
解决一个业务场景中的复杂问题从理解问题域开始，通过专注于问题域并理解复杂问题背后的实质，你才能设计有效的模型来应对业务的挑战。
在项目初期，尽量避免沉溺于技术实现，而要把焦点集中在问题领域，不要忘记技术服务业务的原则。
理解问题域
我们以一个金融场景下的“业务运营监控系统”为例进行分析。经过与运营管理专家和相关业务方的多轮需求探论，我们初步了解了用户的业务诉求和痛点。需要强调的是对于问题域的充分理解是我们的首要任务。
这里整理了一份需求文档，它详细地记录了问题域的具体范围和详细需求。这份文档不仅是业务与技术团队之间的一份沟通文档，也可以作为软件生命周期在需求分析阶段的一个清晰的、规范化的知识协作产物。

文章图片
提炼问题域
理解复杂问题并从中识别、提炼出关键的业务模型，即提炼问题域是领域驱动设计的关键环节。团队可以通过头脑风暴的形式罗列出领域中的所有事件，整合之后形成最终的领域事件集合。
你需要在关键事件标记的范围里，参照不同利益干系方的业务诉求，组织领域事件和模型，同时，你需要整理出与项目关联的上下游系统，如下图所示。

文章图片
通过挖掘隐藏在领域事件中的核心领域模型，我们可以找到从问题空间到方案空间的对应映射关系。针对上述业务监控系统案例， “进件存量”和“进件流量”的概念成为我们发现的重要领域模型。
进件存量：是指在某一指定的时间点，过去生产与积累起来的进件的结存数量。
进件流量：单位时间内流过某一段管道的进件体积流量。
作为衡量业务系统运转状态的重要指标，业务的“存量”状态可以表示业务的积压情况，而业务的“流量”状态可以表示业务流转的变化情况。