方法论 | 领域驱动设计 · 引子
发布于 2021-01-02 13:01
朋友们新年快乐！
上一篇推送开启了一个新话题：微服务。
谈起微服务实践，最先要研究的就是服务的拆分策略。
谈起服务拆分策略，就不得不提到【领域驱动设计】。
于是，我决定先暂停微服务的话题更新，开启一个新话题：方法论。
在这个话题中，我们将探讨一些软件工程的具体实践方法，我们会首先讨论【领域驱动设计】，接着会聊聊【敏捷模式】、【DevOps】。
【领域驱动设计】内容较多，预计会分多次进行推送。
该系列结束后将继续更新微服务话题。
新坑越开越多了呢
软件工程领域的知识谱系，是典型的网状结构，无论我们走深度优先还是广度优先的遍历方式，最终都会殊途同归。
"Wir mussen wissen. Wir werden wissen.（我们必须知道，我们必将知道。）"
—— 戴维·希尔伯特（David Hilbert，1862～1943，德国著名数学家）
DDD是什么？
荐读
大家如果想要深入了解DDD，有两本书是绕不开的，它们分别是《领域驱动设计：软件核心复杂性应对之道（Domain-Driven Design : Tackling Complexity in the Heart of Software）》和《实现领域驱动设计（Implementing Domain-Driven Design）》。前者是DDD理论的开山经典之作，后者更侧重于对理论的诠释与实践。
我们有两类具体的措施来应对这个难题。
一是从技术架构的角度看，我们可以选择服务化的演进策略。二是从流程管理的角度看，我们可以选择实施敏捷模式或DevOps。但是这两类措施的具体实践，归结到设计层面，都要依赖于一个共同的基础，那就是一套完备的业务模型，它在DDD中被称之为 “领域模型”。
运用领域模型
所谓 “模型” ，就是对特定的现实世界的事物的一种抽象与归纳，把与解决问题相关的方面提取出来，忽略无关的东西。每个软件程序是为了执行用户的某项具体业务，或是满足用户的某种需求。这些业务或需求的覆盖范围或知识体系，就是软件的 “领域” 。
从本质上来说，软件开发过程就是从 “问题空间” 到 “解决方案空间” 的一个映射转化。“问题空间” 包括了需求与业务分析，“解决方案空间” 包括了模型、组件、架构、设计与实现方案。领域模型就是 “解决方案空间” 的抽象结构化的归纳。
领域模型能帮助我们做什么？
（1）为了创建真正能为用户业务所用的软件，开发团队必须掌握一整套具体的业务知识体系。所需知识的广度可能令人望而生畏，庞大而复杂的信息也可能超乎想象。开发人员常常对业务知识不感兴趣，抵触情绪让他们难以潜心深入学习，另外时间和效率方面也不会允许。而领域模型对业务知识进行了选择性的简化和有意的结构化，正是解决此类信息超载问题的工具。
（2）领域模型是业务描述的严格且规范的抽象，绝不是主观且随意的。领域模型有助于帮助业务专家和需求分析人员进行高效沟通，通过建立 “通用语言”（在业务层面与技术层面均可以无歧义使用的共同术语），搭建起贯通需求方到开发者的一致性的交流基础，帮助双方识别并保证业务需求的逻辑性、准确性、简洁性。
（3）领域模型伴随代码持续演进，系统的维护和功能扩展都依赖于领域模型。团队新加入的开发人员可以通过领域模型快速理解业务与代码，当用户提出新的需求后，我们也可以基于领域模型进行识别与反馈。
分而治之
DDD 指导下的软件设计主要分为2个部分：战略设计和战术设计。
战略设计层面主要实现了业务的领域划分，DDD 提出了域、子域、限界上下文、通用语言等重要概念；战术设计层面主要实现了业务的领域建模，DDD 提出了实体、值对象、领域服务、领域事件、聚合、工厂、资源库等重要概念。
DDD通过战略设计和战术设计两个层面，将传统的独立模型的方式进行拆解，为每一个子域定义单独的领域模型，采取分而治之的思想，将复杂问题进行有序拆分，各个击破。
在此基础之上，开发过程和代码分析不再是以数据模型为起点，而是以领域模型为起点，这是符合面向对象思想的。一个反面例子是，传统的J2EE的开发模式仅仅面向于数据模型，对象只是数据的载体，缺乏行为和动作的定义，大量的getter和setter淹没了面向对象的本质。这种对象在DDD中被称为贫血领域对象（Anemic Domain Object）。
DDD分而治之的思想与微服务模式不谋而合，在中台建设中也能提供足够标准化的理论指导，这也是DDD近几年火起来的重要原因。
立足小城，侧耳听风
2021年，陪你聊聊云原生、交互设计、技术管理
本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。
相关素材