领域驱动设计包含三层含义：

• 协作层
• 架构层
• 实现层

协作层

协作层强调的是，需求不是无源之水、无根之木，需求有它的来源，追溯上去，需求常常来自技术之外的业务领域。

因此，软件开发不仅仅是软件与编程，而是多种职能的协作，是协同设计（co-design）的过程。

其中基于领域知识而构建起来的团队通用语言，是确保团队成员之间对问题有共识的重要途径。

软件开发过程，是业务领域的知识流向代码实现，再由代码实现的软件收集信息反馈以更新领域知识，如此不断迭代的过程。

每个职能都有推进业务领域认知与共识的义务和使命。

架构层

从业务领域的需求，变成软件实现，常常涉及很多支撑的、辅助的，非核心相关的子需求、子领域，如代码托管、监控、知识库、项目管理平台、IM、运维等。

因此，不是所有需求都一样重要，我们可以根据自身业务领域或商业的核心目标，将需求划分成核心领域、支撑领域、通用领域等。

技术资源是有限的，应当聚焦核心领域，而将辅助的、支撑的，适当外包或购买成熟体系提供的服务。

DDD 的软件架构含义，其主旨就是分辨、权衡哪些需求的代码应该自己实现，而那些应该让其他公司实现。

自己实现的部分，也有领域细分。不同开发团队对不同领域有不同程度的认知。有的团队负责用户 / 登陆 / 鉴权等，他们更通晓该领域的知识，并且在持续更新认知，因为他们掌握了这个领域的权威知识来源和定义权。其他团队在这方面重复劳动，难以长期投入，也很难跟进新的变化。

因此，如何划分技术团队，组织他们之间的领域协作关系，考验的是架构师的设计水平。

中台化的背后，其实就包含领域知识的集中，权威来源的集中，减少重复建设和投入不足的现象。

直观来看，就是代码写在哪里、由谁来写的问题。同一个领域知识和需求，不应有两份互不同步的代码实现。同时迭代多分功能重叠的代码，领域知识的完整性、一致性和延续性难以保障，体现在软件中就是各色的数据或逻辑的前后不一（Bug）。

错误的软件架构及其背后的人员组织架构，常常系统性地滋生上述问题，是导致产品失败的重要诱因和信号。

实现层

需求的代码实现，也并非任意的，随性的，它们应当尽可能反映业务领域里的需求和知识表达。

其中，代数数据类型（Algebraic Data Types，简称 ADT）有着良好的数学性质，通过 Product type, Sum type 和 Exponential type 可以分别表达并存、互斥和转换。

正确使用 ADT 表达领域知识的内在关系，可以利用 compiler 的 type-check 能力，更早更全面地覆盖和保持代码里的领域知识。

简单地用 object/class 去编码领域知识，常常由于它们缺乏表达互斥么能力，而让代码更难以维护，有更多非法状态可能，需要在每一次消费状态数据时，自觉和主动地验证。而每一处的遗漏，都是带来隐患。

Make illegal state unrepresentable ，使用表达能力更强的类型系统，让非法状态难以被表示和构造。

Make illegal operation unrepresentable，使用良好的类型系统和框架设计，让非法操作难以被表达和误用。

比如能力函数 (operation/capability) 通过参数下发，比在全局变量里，或在模块里，更准确和可控，并非随意的模块，可以随意地访问数据和能力，根据领域细分的模块和代码，应当只访问以及只能访问到相关的能力，而非全部的能力，减少误用空间，从而减少多份功能重叠的代码在代码库里滋生和蔓延的概率)。

实现层的理论依据是 Curry-Howard Isomorphism，代码和逻辑是同构的。领域知识的逻辑表达，跟它的代码表达可以是同构的。

这是 DDD 的根基所在，代码应反映领域知识，两者在通用语言的媒介下保持同步，代码与逻辑的同构特性，使同步成为可能。

三层含义之间的关系

协作层是最核心和权威的，它是架构层的设计依据。

架构层的目标就是高效地支撑和满足协作层产生的知识和需求，去编排代码在人力组织架构上的分布（内部、外部、中台、后台、前台、具体业务子领域开发小组等）

实现层则是架构层指导下的具体代码表达，应该遵从架构层的软件规划，避免重复的、不一致的、缺乏可持续性的代码维护，而采取聚焦的、有权威来源的，受到编译器类型检查的、可持续迭代的代码实现。

当协作层发生变化，常常产生人力组织架构的变化，软件架构层需要顺应这种趋势而做出合理的调整，从而代码实现层也发生变化。

协作层 > 架构层 > 实现层
原文链接：https://juejin.cn/post/7051550532917264392