跨越DDD从理论到工程落地的鸿沟

DDD作为一种优秀的设计思想,的确为复杂业务治理带来了曙光。然而又因为DDD本身难以掌握,很容易造成DDD从理论到工程落地之间出现巨大的鸿沟。就像电影里面的桥段,只谈DDD理论姿势很优美,一旦工程落地就跪了……所以DDD的项目,工程落地很重要,否则很容易变成“懂得了很多道理,却依然过不好这一生”

c2189c8672c1d1dbea560e77220c4409_937x405.png@900-0-90-f.png

这篇文章,我会从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

销售人员

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享