DDD作为一种优秀的设计思想,的确为复杂业务治理带来了曙光。然而又因为DDD本身难以掌握,很容易造成DDD从理论到工程落地之间出现巨大的鸿沟。就像电影里面的桥段,只谈DDD理论姿势很优美,一旦工程落地就跪了……所以DDD的项目,工程落地很重要,否则很容易变成“懂得了很多道理,却依然过不好这一生”。
这篇文章,我会从DDD的核心概念讲起,但重点会讲如何把理论落地成代码,期望给那些正在探索DDD的同学一些指引和启发。
1. DDD的核心概念
DDD难以掌握的原因之一是因为其涉及很多概念,比如像Ubiquitous Language、Bounded Context、Context Mapping、Domain、Domain Service、Repository、Aggregation root、Entity、Value Object等等。这里简要介绍一下DDD的核心概念,了解这些概念可以更好的帮助我们落地DDD。
1.1 统一语言
Eric Evans在解释DDD本质的时候,重点提到“Exploration and reshaping the ubiquitous languages”,也就是探索并重塑统一语言。统一语言是DDD中非常重要的概念,因为语言是我们认知的基础,语言都不统一,就像一个人说阿拉伯语,一个人说汉语,那怎么能交流的起来呢?
对于统一语言,我建议每个项目都要有一份自己的核心领域词汇表。这个词汇表至少要包含中文、英文、缩写、解释四列,中文是我们日常交流和文档中经常要体现的,所以需要统一,这样我们在交流的时候才能高效,没有歧义;英文和英文缩写主要体现在我们的设计和代码上,也就是说我们的“统一语言”不仅仅是停留在交流和文档中,还要和代码保持一致,这样才能做到知行合一,提升代码的可读性和系统的可理解性。
比如一个CRM系统,我们可以从业务需求中挖掘出一些重要的领域概念,把这些概念整理成词汇表会如下所示。
中文 |
英文 |
缩写 |
解释 |
客户 |
Customer |
营销对象 |
|
机会 |
Opportunity |
可能成交的机会 |
|
线索 |
Leads |
潜在的客户 |
|
联系人 |
Contact Person |
能联系到客户的关键人 |
|
公海 |
Public Sea |
所有客户经理共享的客户资源 |
|
私海 |
Private Sea |
客户经理独占的客户资源 |
|
客户经理 |
Customer Manager |
CM |
销售人员 |