DDD该如何学?

2006年,国内互联网才刚刚萌芽,大家甚至还不习惯网购,大多数在校生都在宿舍里刷魔兽世界副本。但企业软件开发却得到了蓬勃发展,各大公司和事业单位都纷纷进行信息化转型。

然而大家很快发现,企业应用业务逻辑的复杂度要远远高于技术本身,且企业IT人员很难描述清楚他们真正的业务,广大程序员也普遍缺乏挖掘真正需求的能力。整个开发过程更多的是瀑布式,开发人员一次性收集需求,可能半年后才会和业务人员再次沟通。大多数企业软件就是在这样的环境下硬着头皮上线的,其质量可想而知。

随着《领域驱动设计》中文版的首次发布,DDD(Domain-Driven Design,领域驱动设计)的概念正式进入中国。当时业界普大喜奔,认为它能指导程序员更精准地收集领域知识,进行更合理的设计,企业应用的银弹出现了。

当时的我正处于多层架构的启蒙阶段,挣扎于企业系统的泥潭,又刚刚被Martin Fowler的《企业应用架构》洗了一遍脑,自然也随波逐流地买了一本,捧在手里翻来翻去,但反反复复就是看不懂。当时以为在贫血模型里面加几个方法就是领域模型了,把DAL或DAO改名成Repository就是资源库了。而且身为程序员,自然愿意去关注那些能指导我们写代码的战术设计方法,对那些真正能帮助我们进行合理设计的战略设计方法,则视而不见(可能是因为看也看不懂)。

多年过去,这本书仍然作为我的镇宅之宝戳在书架显眼的位置,希望能有识货的朋友来访时能一眼瞧见,伸出大拇指羡慕嫉妒地说“这么老的书你都有”。或者偶尔拿出来拍张照片在朋友圈晒晒,以炫耀自己当初的见识。顺便翻开一页,把鼻子凑上去闻一闻来自12年前的墨香。

7年之后Vaughn Vernon出版了Implement Domain-Driven Design,简称IDDD。一年之后由同事翻译的中文版《实现领域驱动设计》也相应出版,当时被看做是能让DDD落地的书(毕竟书名里有个“实现”嘛)。然而我在项目技术负责人的带领下,在众多有经验的架构师的指导下,仍然没有弄明白。之前看过的相关知识均已遗忘殆尽。限界上下文、上下文映射这些名词只是似曾相识。

两年之后《领域驱动设计模式、原理与实践》问世,简称PPPDDD。社区对这本书的评价非常之高,甚至认为在IDDD之上。只可惜这本书的翻译质量并不高,我翻了几页之后又束之高阁了。

今年年初,项目上的架构小组又开始组织学习DDD。所使用的“教材”是英文版的PPPDDD。在同事的激励下,我开始重整旗鼓,啃这本英文版大部头。开始精读之后,才发现这是一本很水的好书。说它水是因为它的编排并不足够细心,甚至有不同章节的两段文字完全相同的现象,还会花30页的篇幅去介绍一个基于NHibernate的资源库实现。说它好是因为面面俱到,把所有战略模式和战术模式都介绍了个遍,还有大量代码去帮你实现各种战术模式,可以说相当落地。

在学习的过程中,我常常翻阅IDDD中的相关章节进行补充阅读,发现当初晦涩难懂的概念慢慢变得容易起来。应用服务和领域服务不再傻傻分不清楚,不同的上下文映射方式也能在工作中找到对应的例子。对于DDD,感觉快要开始入门了。

与此同时,IDDD的精华版DDDD(Domain-Driven Design Distilled)也出版了。作者总结了过去几年在DDD方面的实战经验,将IDDD中的诸多内容精简升华。在很多概念处都标注了IDDD中的相关章节,可以算是IDDD的一个索引。

其中文版《领域驱动设计精粹》由ThoughtWorks同事覃宇和笪磊合作翻译。这是我读过的最良心的一本书籍,因为它包含了大量译者注解,解释了很多书中没有解释清楚的概念(毕竟是精粹本)。还有些有争议的观点,译者也毫不客气地给出自己的看法。

像这样注解超过原文的情况在其他书中是很少见的。每一处注解都倾注了译者的心血和精力,这背后势必包括大量资料的查阅和研究,而且很多解释都夹带了浓浓的ThoughtWorks特色,使得这样一本薄薄的书变得丰满充实起来。

如果你读书快的话,可能两个小时就读完这样一本书。但如果把原书和注解中的推荐文章和书籍读完,恐怕要一个月。我顺着书中的指引,找到了ThoughtWorks洞见上的所有DDD文章,读完之后,世界观崩塌了,感觉自己刚要入门就要放弃了。具体原因请参考链接中的文章。

其实,不管是DDD、IDDD、PPPDDD还是DDDD,讲的都是理论,充其量会附加一些作者杜撰的示例。相信我,光学习理论是没有用的,你必须将其应用于实践,在自己的真实项目里演练DDD。这时你才会发现,那些白纸黑字的概念,在读书时似乎搞清楚了,但一使用起来,反而更迷惑了。就像最基本的子域和限界上下文的关系问题,ThoughtWorks的首席咨询师肖然就和Vaughn Vernon的理解就相去甚远。到底该“信谁”?那就似乎更要通过实践来出真知了。


更多精彩洞见,请关注微信公众号:思特沃克

Share

DDD的终极大招——By Experience

以DDD思想和微服务架构为代表的新的架构时代正在逐步形成,不同方法和工具的涌现让人激动不已,同时这个过程也让人感觉到些许的不安,因为没有一套方法和一套架构能够打遍天下,我们能明确告诉所有组织和团队的,也只是架构设计上应该“响应变化胜过遵循计划”!具体到采用哪一种架构设计思想和方法,仿佛都需要增加一个定语“这取决于……”。

以去年的“明星”方法Event Storming(ES)为例,今年已经开始被不少人所批判。内行已经开始调侃这就是“糊墙”(不明就里的同学可以感受下图中的ES现场)。而实际上ES创始人Alberto是一位很低调的实践者,仍然在不停地磨练着他发明的这套方法。一年里我也接到了无数类似“我们是xxx领域,有xxx系统,ES感觉好像用不上?”的问题。我的答案往往是:“没事儿,你们先试试,找到具体困难点,咱们再看为啥不好用。”

(一个ES现场,“糊”满各色纸贴的建模过程。)

我相信得到这个答案的部分团队可能真的去尝试了ES,但鲜有人再将他们遇到的具体困难反馈给我 —— 也许ES实践本身就是困难,而不是他们要解决的业务问题。但我的出发点却并非推广ES,而是让团队能够获取“经验”!这点上还是小有成就的,去年我可能还是中国区“糊墙”最多的人,今年很多人都远胜过我了。

不管是在DDD原著,还是后续不少专家的书籍中,都明示或暗示架构设计最后的终极大招还是By Experience ——靠经验吃饭。从战略角度的subdomain(子问题域的划分)到战术建模层面Entity、VO的选择,最终的决策很可能不是完全“理性”,经验这个“感性”的东西发挥着很大的作用。

对于一个顾问和教练来说这是绝望的答案,因为我们每次面对的是希望学习,但没有经验的团队,“靠经验吃饭”等于告诉团队这东西没套路、靠感悟。这就迫使我们转换视角,从教大家DDD方法,转换到帮助大家获取DDD经验。下面就让我们来看看怎么有效解决DDD经验获取这个问题。

问题、问题、问题

DDD作为一种架构方法,最大的突破应该说是非常明确地区分出了问题域和解决方案域。而认知问题这件事情绝对不是技术人员擅长的,从我们学习编程起,我们就被如设计模式(Design Pattern)这样的解决方案所包围。想当年我自己最得意的事情也是refactor to pattern,也是把解决方案当成了“终极问题”来追求。

这往往是一个痛苦的蜕变,需要有人在你身边不停念叨“你说的问题是什么?”。你必须要做到心平气和,即使你认为对方是故意挑衅,有时候挑战更能促进思考上的突破。比如我经历过下面的一段经典对话:

甲:我认为这个子问题域是客户账户管理的问题。

乙:我觉得你已经在说解决方案了。

甲:客户账户管理是问题,我并没有提怎么管理啊!

乙:谁说一定要管理客户?!我还是觉得你说的是解决方案!

甲:(受不了你了… … )不管理客户我们做这个系统干啥?

乙:我就是这个意思啊,为啥要做这个系统?我们解决了什么业务问题?

甲:这么说的话那把业务找过来,看他们怎么说。

乙:行,反正DDD里说领域专家很重要,业务来了再讨论。

某种意义上这两位技术人员的争论是卓有成效的,最终的发现是业务问题其实并不清楚,远没有达到可以进入解决方案建模讨论的时候。

跨领域合作

当然上面的对话还有另外一个有意思的核心观点,即由于问题和解决方案在整个建模过程中是不停深入和迭代的,所以我们必须鼓励,甚至要求从业务到技术跨领域的人员参与和协作。

这点是我为什么仍然认为ES是一个好方法的基础,当然与我相对的观点是,如果有了真正的领域专家,搞那么复杂的协作有必要吗?ES通过对事件(event)的利用,提供了一套业务和技术能够共同理解的协作机制。在我的辅导过程中,很容易让两边的同学都理解如何上手。

(ES的运作机制,很有效的利用了Domain Event;注意这里的event是业务事件,而非技术实现。我的同事伍斌在自己的简书中详细记录ES的采用过程,欢迎大家查阅。)

当然如果真有经验丰富的领域专家,确实事情就简单了很多。业务问题的分解首先就变得非常流畅,ES的功效也就不那么明显了。然而我个人始终认为“团队共同的学习 胜于 建模本身的正确性”,即使专家也不能完全预见未来,所以团队能够有机会通过某种手段学习专家的知识,也是很有价值的一件事情。

从需求到代码

DDD最初吸引我的地方是能够从问题分析一直拉通到代码实现,这有别于很多其它的架构方法,总是在某个链条上产生脱节。所以DDD的经验获取也需要尝试让团队端到端的拉通体验。

然而事实上很多团队仍然在践行着脱节的实践,比如建模后产生的Entity仍然用传统的数据和行为分离的实现方式。这样的实践方式显然是有悖于DDD的初衷,如果不能让业务和系统模型实现绑定关系,很快就会走上各说各话的老路上去。

实践端到端也有一定的技巧,首先应该明确分层架构的原则和规范,比如是否有Application Service存在的必要,Interface的调用规则等等。在此基础上,需要明确守护Domain Model的纪律,时刻保证代码和建模的一致性。最后需要建立分层的测试机制,特别是对Domain层逻辑的守护。

和前两点相比,这真是一个需要全队刻意练习的过程,坚持信念是团队走过开始阵痛期的必要条件。

刻意“失败”

之前在辅导团队的时候,一个常见问题就是团队纠结于一个业务概念建模采用Entity,还是VO。经常会听到团队说:“从现在的需求来看,VO应该是完全够用了,但很显然接下来我们马上就需要有业务状态的变化,很可能VO就没法玩了。”

针对这样的问题,我往往会刻意引导团队从简单的VO建模入手,先不要考虑“未来”的需求,即使有时候这些需求已经相当明确。这样的刻意行为显然会造成团队在接下来的时间里改变模型,VO可能会被重新建模成Entity。短时间有可能是痛苦的,很多技术人员也会跳起来说,你这是“站着说话不腰疼”。

但DDD的核心就在于持续的演进,演进就意味着模型和实现的改变。这样的改变和上面我们刻意安排的“失败”其实是一致的。当我们通过这样的刻意练习获取了演进的经验后,业务和架构未来的变化对我们来说就真的可以by experience了。

写在最后

开篇我就提到了一个新的架构时代正在浮现,不同于之前的架构方法,没有一个组织和企业会在这个时代告诉你这就是做架构的正确方式。数字化时代的系统和应用在不停进化着,速度越来越快,想要找到进化过程中正确的元方法是非常困难的。

DDD的终极大招By Experience某种意义上是在持续探索,并要求大家接受在这个探索过程中的不确定性 —— 你的设计有可能在未来被证明是错误的。这可能是未来架构设计最大的挑战,我们必须能够让架构持续演进。

《演进式架构》已于今年问世,带给我们很多这些方面的思考,类比人类社会的演进,数字化世界的构建和发展应该有很多地方可以借鉴和学习。当然就这个问题而言,不管是DDD,还是Microservices,都只是我们探索架构演进的开始,我们还有很多的Experience需要获取!


更多精彩洞见,请关注微信公众号:思特沃克

Share

DDD战术篇:领域模型的应用

领域驱动设计DDD在战术建模(后文简称建模,除非特别说明)上提供了一个元模型体系(如下图),通过这个元模型我们会对战略建模过程中识别出来的问题子域进行抽象,而通过抽象来指导最后的落地实现。

(DDD构建的元模型元素脑图)

这里我们谈的战术阶段实际就是这样一个抽象过程。这个抽象过程由于元模型的存在实际是一定程度模式化的。这样的好处是并非只能技术人员参与建模,业务人员经过一定的培训也是完全可以理解的。在带领不少团队实践建模的过程中,业务人员参与战术设计也是我要求的。

由于已经有不少书籍介绍DDD的元模型,这里我们就不再赘述,转而谈谈这个抽象过程中大家经常遇到的一些困惑。这些比较常见的问题可能是DDD元模型未来演进需要解决的,但我们仍然要注意业务问题和架构设计的多样性,不要过度规范,以至于过犹不及。

业务对象的抽象

通过对业务问题的子域划分,我们找到了一些关键的业务对象。在开始进行抽象前一个必须的步骤就是“讲故事”!

讲什么故事呢?关于这个子域解决的业务问题或者提供的业务能力的故事。既然是故事,就必须有清晰的业务场景和业务对象之间的交互。这件事情看起来是如此自然和简单,然则一个团队里能够站起来有条不紊陈述清楚的却没有几人。读到这里的读者不妨停下来试试,你是否能够把现在你所做的业务在两三分钟内场景化地描述出来?

这么做显然目的是让我们能够比较完整地思考我们所要提炼和抽象的业务对象有哪些。只有当我们能够“讲”清楚业务场景的时候,才应该开始抽象的步骤。对于一个业务对象,我们常见的抽象可以是“实体”(Entity)和“值对象”(Value Object)。

这两个抽象方式在定义上的区别是,实体需要给予一个唯一标识,而值对象不需要(可以通过属性集合标识)。当然另外一个经常引用的区别是,实体应该是有一个连续的生命周期的,比如我们在一个订单跟踪领域里抽象订单为一个实体,那么每个订单应该有一个唯一识别号,订单也应该有从下单创建到最后交货完成的生命周期。

显然,如果不增加其它约束条件,值对象的抽象是没有意义的,都用实体不就行了?但如果我们稍微思考一下一个实体的管理成本,比如需要保证生命周期中实体状态的一致性,那么我们就会发现值对象变得很简单很可爱。当一个对象在我们(抽象)的世界里不能改变的时候,一切都变得简单了,这个对象被创建后只能被引用,当没有引用时我们可以把它交给垃圾回收自动处理。

随着高并发、分布式系统的普及,实际上我们在对业务对象抽象的第一步思考是能否用值对象。如果大家实现的技术架构采用函数范式的语言(类似Closure),那么首先考虑值对象抽象可能就是一个建模原则了。

对象抽象初步完成后,一定要再重复一次之前的故事来审视一下我们的建模。经历这个抽象过程后,参与讨论的每个人都应该发现自己更清晰业务的需求和需要提供的能力了。

聚合的封装

DDD元模型中一个核心概念叫“聚合”(Aggregate)。这个从建筑学来的名词非常形象,建筑学上我们翻译为“骨料”,是形成混凝土的重要元素,也是为什么混凝土如此坚固的基础。

(混凝土里的一种骨料)

同理,在DDD建模中,聚合也是我们构建领域模型的基础,并且每个聚合都是内聚性很高的组合。聚合本身完成了我们对骨干业务规则的封装,减小了我们实现过程中出错的可能。

以上面那个订单跟踪领域为例,假设我们允许一个订单下存在多个子订单,而每个子订单也是可以独立配送的,这种情况下我们抽象出“子订单”这个实体。显然订单和子订单存在业务逻辑上的一致性,没有订单的时候不应该创建子订单,更新子订单的时候应该同时“通知”所属的订单。这个时候如果采用把订单和子订单聚合起来的封装就很有必要了。

采用聚合抽象的结果就是访问每个子订单都需要从相关的订单入口(i.e., 订单为聚合根),存取时我们都是以这个聚合为基本单位,即包含了订单和订单下面的所有子订单。显然这样的好处是在订单跟踪这个领域模型里,订单作为一个聚合存在,我们只需要一次性梳理清楚订单和子订单的逻辑关系,就不需要在未来每次引用时都考虑这里面的业务规则了。

(订单跟踪领域的订单聚合)

在建模过程中,很多团队并没有努力思考聚合的存在。封装这个在技术实现领域的基本原则在建模时却很少被重视起来。开篇提到在战术建模过程中强调业务领域人员的参与也是为了解决这个问题,聚合的识别实际是针对业务规则的封装,当我们不理解业务规则的时候是无法做出是否封装的判断的。

一言以蔽之,识别聚合是认知潜在核心业务规则的过程,而定义出来的聚合是在大家共识基础上对核心业务规则的封装。

领域服务的定义

在最初的元模型定义里,领域服务让不少人纠结,一个经典的例子是在账户管理领域里对“转账”这个业务行为的抽象。由于转账本身是作用在至少两个账户上的,所以把转账作为一个账户的行为显然是不合适的。那么如果我们把转账名词化抽象成一个实体呢?感觉也是比较别扭,毕竟转账是依附于账户存在的。

这个时候DDD在元模型里提出了服务(Service)这个抽象,转账被抽象为一个服务感觉就顺畅多了。同样道理,在我们上面的订单跟踪领域里,如果跟踪的过程中需要进行短信的通知,一个比较好的建模就是抽象出一个“通知”服务来完成。

我经常会用静态方法来帮助技术人员理解服务的抽象(虽然服务并不一定用静态方法来实现)。服务本身就像一个静态方法一样,拥有一定的逻辑但不持有任何的信息,从整个领域来看也不存在不同“版本”的同一个服务。

一个经常困扰大家的问题是对Service这个词语的限定,有的分层架构设计里会出现领域服务(Domain Service)和应用服务(Applicaiton Service)。大多数时候应用服务在领域服务的上层,直接对外部提供接口。如果存在这样的分层,那么领域服务就不应该直接对外,而应该通过应用服务。

举个例子,前面的订单消息通知如果是一个领域服务,在完成订单状态变化时创建通知消息,而最后的通知以短信的方式发给设定的人群,这样就应该有一个相应的应用服务,包含了具体的业务场景处理逻辑。之后也可能有一个邮件通知的应用服务,同样调用了这个通知领域服务,但通过邮件渠道来完成最终的业务场景。

由于微服务架构的流行,每个子领域的粒度已经相当细了,很多时候已经没有这样的领域服务和应用服务的区分了。当然从简单性角度出发这是好事情。在整个建模过程中,服务的抽象往往是最不确定的,也是最值得大家反复斟酌的地方。

Repositories的使用

Repositories是一个非常容易被误解的抽象,很多人会直接联想到具体的数据存储。在初期采用DDD建模的时候,我经常刻意回避这个抽象,避免让大家陷入思考紊乱。

这个抽象概念实际可以追溯到Martin Fowler的Object Query模式。另外一个相关概念是DAO(Data Access Object),都是用来简化需要存储的数据和对应的业务对象之间的映射关系。不同的是Repositories针对更加粗颗粒度的抽象,在DDD这个方法里我们可以认为映射对象是我们的聚合。针对每个实体在实现时候也可能创造出对应的DAO(比如采用Hibernate这样的ORM框架),但显然在建模过程中不是我们需要关注的。

那么Repositories的抽象为什么是必要的呢?让我们再回到订单跟踪这个例子,通知订单状态发生变化的服务在发出通知前,需要定位到订单的信息(可能包括订单的相关干系人和子订单的信息)。通知作为一个服务是不应该持有具体订单信息的,这个时候我们就需要通过Repositories的抽象来建立对订单这个聚合的查询,即有一个订单的repo,而具体的查询逻辑应该在这个repo中。

这样的抽象在需要存储和查询值对象的时候也是必要的。假设我们分析订单查询这个领域,在这个领域里订单记录显然已经不允许修改了,自然的抽象方式就是值对象。同时一个查询的服务来持有具体的查询逻辑(比如按时间或用户)是合理的。外部应用直接调取了查询服务(接口)并给出规定的参数,我们就需要一个订单记录的repo来持有跟存储相关的查询逻辑。当然这并不是说有一个查询就一定有一个repo与之对应,如果查询的逻辑非常简单,未尝不可以让服务直接针对数据存储实现。记住我们抽象的目标是让建模更简单,抽象过程中应该保持灵活。

限界上下文的意义

经过最近10多年的演进,我们在如何支撑一个组织的规模化上达成了一些基本的共识。我们知道微服务架构(Microservices)能够帮助我们把成百上千的工程师们组织起来,而小团队的自组织性是至关重要的。我们也逐步就如何能够在技术和业务团队之间明确沟通“架构”这个难题上找到了DDD。那么DDD和微服务架构的关系是什么呢?很多人会提到限界上下文(Bounded Context)。

我曾经就这个话题专门撰文一篇(DDD&Microservices)。一个限界上下文封装了一个相对独立子领域的领域模型和服务。限界上下文地图描述了各个子领域之间的集成调用关系。这个定义某种意义上和我们的微服务划分不谋而合:以提供业务能力为导向的、自治的、独立部署单元。所以虽然我们不能百分百依据限界上下文划分服务,但限界上下文,或者说是DDD,绝对是我们设计微服务架构的重要方法之一。

如果我们再追溯到DDD的战略设计,我们会发现在问题域上,DDD通过子问题域(subdomain)的划分就已经进行了针对业务能力的分解,而限界上下文在解决方案域中完成了进一步分解。当然我们不能完全认为子问题域和限界上下文有严格意义上的一对一关系,但大多数情况下一个子问题域是会被设计成一个或多个限界上下文的。子域subdomain和限界上下文某种意义上是互相印证的,重点在区分问题域和解决方案域,这是落地DDD最困难的地方,也是判断一个架构师能力进阶的分水岭。

战术建模小结

DDD的建模元素比较简洁,本文中叙述的元模型应该是满足了大多数场景下的建模。毛主席曾经有一句名言“战略上要藐视敌人 战术上要重视敌人”,就架构设计来说我们没有敌人,业务需求是我们的朋友。所以在领域驱动的架构设计方面,咱们需要的是“战略上要重视朋友,战术上要简化建模”。希望这句话能够帮助正在实践DDD的团队重新思考自己在战略问题域的投入和重视程度,不要挥舞着战术模型的大锤到处寻找实际不存在的钉子。

在这里我们也希望通过第一届DDD China建立起一个架构设计人员的交流平台。期待更多的中国技术人员能够通过这个平台和世界一流架构大师们建立起沟通的渠道,不仅在战略层面,也在战术层面和所有人一起分享讨论关于DDD的一切。


更多精彩洞见,请关注微信公众号:思特沃克

Share

DDD实战篇:分层架构的代码结构

不同于其它的架构方法,领域驱动设计DDD(Domain Driven Design)提出了从业务设计到代码实现一致性的要求,不再对分析模型和实现模型进行区分。也就是说从代码的结构中我们可以直接理解业务的设计,命名得当的话,非程序人员也可以“读”代码。

然而在整个DDD的建模过程中,我们更多关注的是核心领域模型的建立,我们认为完成业务的需求就是在领域模型上的一系列操作(应用)。这些操作包括了对核心实体状态的改变,领域事件的存储,领域服务的调用等。在良好的领域模型之上,实现这些应用应该是轻松而愉快的。

笔者经历过很多次DDD的建模工作坊,在经历了数天一轮又一轮激烈讨论和不厌其烦的审视之后,大家欣慰地看着白板上各种颜色纸贴所展示出来的领域模型,成就感写满大家的脸庞。就在这个大功告成的时刻,往往会有人问:这个模型我们怎么落地呢?然后大家脸上的愉悦消失了,换上了对细节就是魔鬼的焦虑。但这是我们不可避免的实现细节,DDD的原始方法论中虽然给出了“分层架构”(Layered Architecture)的元模型,但如何分层却没有明确定义。

分层架构

在DDD方法提出后的数年里,分层架构的具体实现也经历了几代演进,直到Martin Fowler提炼出下图的分层实现架构后,才逐步为大家所认可。DDD的方法也得到了有效的补充,模型落地的问题也变得更容易,核心领域模型的范围也做出了比较明确的定义:包括了Domain,Service Layer和Repositories。

(Martin Fowler总结提出的分层架构实现,注意“Resources”是基于RESTful架构的抽象,我们也可以理解为更通用的针对外界的接口Interface。而HTTP Client主要是针对互联网的通信协议,Gateways实际才是交换过程中组装信息的逻辑所在。)

我们的核心实体(Entity)和值对象(Value Object)应该在Domain层,定义的领域服务(Domain Service)在Service Layer,而针对实体和值对象的存储和查询逻辑都应该在Repositories层。值得注意的是,不要把Entity的属性和行为分离到Domain和Service两层中去实现,即所谓的贫血模型,事实证明这样的实现方式会造成很大的维护问题。DDD战术建模中的元模型定义不应该在实现过程中被改变,作为元模型中元素之一的实体本身就应该包含针对自身的行为定义。

基于这个模型,下面我们来谈谈更具体的代码结构。对于这个分层架构还有疑惑的读者可以精读一下Martin的原文。有意思的一点是,这个模型的叙述实际是在微服务架构的测试文章中,其中深意值得大家体会。

这里需要明确的是,我们谈论代码结构的时候,针对的是一个经过DDD建模后的子问题域(参见战略设计篇),这是我们明确的组件化边界。是否进一步组件化,比如按照限界上下文(Bounded Context)模块化,或采用微服务架构服务化,核心实体都是进一步可能采用的组件化方法。从抽象层面讲,老马提炼的分层架构适用于面向业务的服务化架构,所以如果要进一步组件化也是可以按照这个代码结构来完成的。

总体的代码目录结构如下:

- DDD-Sample/src/
    domain
    gateways
    interface
    repositories
    services

这个目录结构一一对应了前文的分层架构图。完整的案例代码请从GitHub下载

可以看到实际上我们并没有建立外部存储(Data Mappers/ORM)和对外通信(HTTP Client)的目录。从领域模型和应用的角度,这两者都是我们不必关心的,能够验证整个领域模型的输入和输出就足够了。至于什么样的外部存储和外部通信机制是可以被“注入”的。这样的隔离是实现可独立部署服务的基础,也是我们能够测试领域模型实现的要求。

模型表达

根据分层架构确立了代码结构后,我们需要首先定义清楚我们的模型。如前面讲到的,这里主要涉及的是从战术建模过程中得到的核心实体和服务的定义。我们利用C++头文件(.h文件)来展示一个Domain模型的定义,案例灵感来源于DDD原著里的集装箱货运例子。

namespace domain{
struct Entity
{
    int getId();
protected:
    int id;
};

struct AggregateRoot: Entity
{
};

struct ValueObject
{
};

struct Provider
{

};

struct Delivery: ValueObject
{
    Delivery(int);
    int AfterDays;
};

struct Cargo: AggregateRoot
{
    Cargo(Delivery*, int);
    ~Cargo();
    void Delay(int);
private:
    Delivery* delivery;
};
}

这个实现首先申明了元模型实体Entity和值对象ValueObject。实体一定会有一个标识id。在实体的基础上声明了DDD中的重要元素聚合根 AggregateRoot。根据定义,聚合根本身就应该是一个实体,所以AggregateRoot继承了Entity。

这个案例中我们定义了一个实体Cargo,同时也是一个聚合根。Delivery是一个值对象。虽然这里为了实现效率采用的是struct,在C++里可以理解为定义一个class类。

依赖关系

代码目录结构并不能表达分层体系中各层的依赖关系,比如Domain层是不应该依赖于其它任何一层的。维护各层的依赖关系是至关重要的,很多团队在实施的过程中都没有能够建立起这样的工程纪律,最后造成代码结构的混乱,领域模型也被打破。

根据分层架构的规则,我们可以看到示例中的代码结构如下图。

Domain是不依赖于任何的其它对象的。Repositories是依赖于Domain的,实现如下:引用了model.h。

#include "model.h"
#include <vector>

using namespace domain;

namespace repositories {
struct Repository
{
};
...

Services是依赖于Domain和Repositories的,实现如下:引用了model.h和repository.h

#include "model.h"
#include "repository.h"

using namespace domain;
using namespace repositories;

namespace services {
struct CargoProvider : Provider {
    virtual void Confirm(Cargo* cargo){};
};

struct CargoService {
    ... ...
};
...

为了维护合理的依赖关系,依赖注入(Depedency Injection)是需要经常采用的实现模式,它作为解耦合的一种方法相信大家都不会陌生,具体定义参见这里

在测试构建时,我们利用了一个IoC框架(依赖注入的实现)来构造了一个Api,并且把相关的依赖(如CargoService)注入给了这个Api。这样既没有破坏Interface和Service的单向依赖关系,又解决了测试过程中Api的实例化要求。

auto provider = std::make_shared< StubCargoProvider >();

api::Api* createApi()  {
    ContainerBuilder builder;
    builder.registerType< CargoRepository >().singleInstance();
    builder.registerInstance(provider).as<CargoProvider>();
    builder.registerType< CargoService >().singleInstance();
    builder.registerType<api::Api>().singleInstance();

    auto container = builder.build();

    std::shared_ptr<api::Api> api = container->resolve<api::Api>();

    return api.get();
}

测试实现

有了领域模型,大家自然会想着如何去实现业务应用了,而实现应用的过程中一定会考虑到单元测试的设计。在构建高质量软件过程中,单元测试已经成为了标准规范,但高质量的单元测试却是困扰很多团队的普遍问题。很多时候设计测试比实现应用本身更加困难。

这里很难有一个固定标准来评判某个时间点的单元测试质量,但一个核心的原则是让用例尽量测试业务需求而不是实现方式本身。满足业务需求是我们的目标,实现方式可能有多种,我们不希望需要持续重构的实现代码影响到我们的测试用例。比如针对实现过程中的某个函数进行入参和出参的单元测试,当这个函数发生一点改变(即使是重命名),我们也需要改动测试。

测试驱动开发TDD无疑是一种好的实践,如果应用得当,它确实能够实现我们上述的原则,并且能够帮助我们交流业务的需求。比较有意思的是,在基于DDD建立的核心模型之上应用TDD似乎更加顺理成章。类比DDD和TDD虽然是不恰当的,但我们会发现两者在遵循的原则上是一致的,即都是面向业务做分解和设计:DDD就整个业务问题域进行了分解,形成子问题域;TDD就业务需求在实现时进行任务分解,从简单场景到复杂场景逐步通过测试驱动出实现。下面的测试用例展现了在核心模型上的TDD过程。

TEST(bc_demo_test, create_cargo)
{
    api::CreateCargoMsg* msg = new api::CreateCargoMsg();
    msg->Id = ID;
    msg->AfterDays = AFTER_DAYS;
    createCargo(msg);
    EXPECT_EQ(msg->Id, provider->cargo_id);
    EXPECT_EQ(msg->AfterDays, provider->after_days);
}

上面测试了收到一条创建信息后实例化一个Cargo的简单场景,要求创建后的Cargo的标识id跟信息里的一致,并且出货的日期一致。这个测试驱动出来一个Interface的Api::CreateCargo。

下面是另外一个测试推迟delay的场景,同样我们看到了驱动出的Api::Delay的实现。

TEST(bc_demo_test, delay_cargo)
{
    api::Api* api = createApi();
    api::CreateCargoMsg* msg = new api::CreateCargoMsg();
    msg->Id = ID;
    msg->AfterDays = AFTER_DAYS;
    api->CreateCargo(msg);
    api->Delay(ID,2);
    EXPECT_EQ(ID, provider->cargo_id);
    EXPECT_EQ(12, provider->after_days);
}

长期以来对于TDD这个实践大家都有架构设计上的疑惑,很多资深架构师担心完全从业务需求驱动出实现没法形成有效的技术架构,而且每次实现的重构成本都可能很高。DDD的引入从某种程度上解决了这个顾虑,通过前期的战略和战术建模确定了核心领域架构,这个架构是通过预先综合讨论决策的,考虑了更广阔的业务问题,较之TDD应用的业务需求层面更加宏观。在已有核心模型基础上我们也会发现测试用例的设计更容易从应用视角出发,从而降低了测试设计的难度。

关于预先设计

如果没有读战略篇直接看本文的读者肯定会提出关于预先设计的顾虑,毕竟DDD是被敏捷开发圈子认可的一种架构方式,其目标应该是构建架构模型的响应力。而这里给大家的更多是模式化的实现过程,好似从建模到代码一切都预先设计好了。

值得强调的是,我们仍然反对前期设计的大而全(Big-Design-Up-Front,BDUF)。 但我们应该认可前期对核心领域模型的分析和设计,这样能够帮助我们更快地响应后续的业务变化(即在核心模型之上的应用)。这不代表着核心领域模型未来会一成不变,或者不能改变,而是经过统一建模的核心部分变化频率较之外部应用会低很多。如果核心领域模型也变化剧烈,那么我们可能就要考虑是否业务发生了根本性的变化,需要建立新的模型。

另外不能忘记我们预先定义的模型也是被局限在一个分解出来的核心问题域里的,也就是说我们并不希望一口气把整个复杂的业务领域里的所有模型都建立起来。这种范围的局限某种程度上也限制了我们预先设计的范围,促使我们更多用迭代的方式来看待建模工作本身。

最后显然我们应该有一个核心团队来守护核心领域模型,这不代表着任何模型的设计和改动都必须由这个团队的人做出(虽然有不少的团队确实是这样落地DDD的)。我们期望的是任何对核心模型的改动都能够通过这个核心团队来促进更大范围的交流和沟通。检验一个模型是否落地的唯一标准是应用这个模型的团队能否就模型本身达成共识。在这点上我们看到很多团队持续通过代码走查(code review)的方式在线上和线下实践基于核心模型的交流,从而起到了真正意义上的“守护”作用,让模型本身成为团队的共同责任。

实践DDD时仍然需要遵循“模型是用来交流的”的这一核心原则。我们希望本文介绍的方法及模式能够帮助大家更容易地交流领域模型,也算是对DDD战略和战术设计的一点补充。


更多精彩洞见,请关注微信公众号:思特沃克

Share

DDD战略篇:架构设计的响应力

当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时,鲜有组织会真正把这句话当回事儿,甚至很多经验丰富的管理者会认为好的计划是成功的一半,遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中,可能很多管理者已经不会简单满足于“响应”,而是选择主动发起变化了。不确定性管理成了这个时代的主旋律,企业的响应力成了成败的关键。

随着这种趋势的深入,架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义,很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性,保证不会因为某个局部的问题而造成全身瘫痪。

然而架构的健壮性却比较难于定义和测试,以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里,当你询问一位资深工程师架构设计时,往往会得到一张搭积木一样的“架构图”。

图的底层是各种数据存储(从经典的Oracle到大数据标配的Hadoop),图的中间是类似Kafka这样的消息管道和传统的ESB(消息总线),上层则是各种业务应用(包括各种Web应用和移动的APP)。

仿佛这是一个流行的“稳定”架构设计。

(示意:典型的IT系统架构图)

当询问这样的架构是否合理时,不少人会告诉你问题可大了:这不是云时代的服务化架构。原因是这个架构的大部分组件,如数据存储,都已经可以完全“托管”给云平台了。于是乎,很多企业架构师又开始寻找像过去ESB一样能够对接各种云平台的PaaS了,然后抱怨现在的PaaS没有当年的ESB“稳定”。

两个核心问题却很少被提及:

  1. 当年基于ESB集成的SOA服务化架构解耦出的组件不但没有提升效率,反而增加了系统后续修改的复杂度。
  2. 看似“以不变应万变”的架构并不能支撑多样化的业务需求,最后各个业务部门仍然有一套自己的IT系统,即便是画出来的架构图惊人的相似(多少次有人惊呼“这就是我们之前那个工作流系统~”)。

就这两个核心痛点,让我们一起来谈谈架构设计面临的挑战和应对方式。

什么是架构设计

由于软件设计是一个复杂度很高的活动,“通过组件化完成关注点分离从而降低局部复杂度”很早就成为了咱们这个行业的共识。前面提到的数据存储、消息管道等“模块”在某种意义上都是组件化的产物。这样的好处是在不同系统里遇到同样的功能需求时可以复用。在云服务崛起的今天,这样的组件以“服务”的形式更容易为我们所采用。

当然技术出身的架构师们在架构设计的时候或多或少都有一种“搭积木”的感觉。大家都非常关注Kafaka有哪些功能,K8S是不是比Mesos功能更全,以及Akka是不是稳定。就像走进一个家装公司,在选择了“套餐”之后有工程人员给你介绍地砖和木地板用哪个品牌更好。

回到咱们的第二个核心痛点,如果只是这样的搭积木,为什么咱们总是在面对新变化、新需求的时候发现需要新的组装方式或新的组件呢?这样的架构设计对比直接按照需求实现(不考虑架构)有什么优势呢?

这里我们应该回到架构设计的本质,即为什么我们要在代码实现前做设计。显然如果去掉设计这个过程,大家会说问题这么复杂,如何下手啊?所以设计首先是要解决问题的复杂度。于是有人做了一个架构,交给了一个团队去实现,很快发现实现的架构和设计完全是两张皮。当然原因很明确——缺少了交流和沟通,所以设计其次是要建立团队协作沟通的共识

假设我们产生了一个团队都达成共识的架构设计,大家都兢兢业业把设计变成了现实。一个长期困扰软件行业的问题出现了,需求总是在变化,无论预先设计如何“精确”,总是发现下一个坑就在不远处。相信很多技术人员都有这样的经历,结果往往是情况越来越糟糕,也就是我们常说的架构腐化了,最后大家不得不接受重写。这些经历让我们逐步明确了软件架构设计的实质是让系统能够更快地响应外界业务的变化,并且使得系统能够持续演进。在遇到变化时不需要从头开始,保证实现成本得到有效控制。

面向业务变化而架构

基于上面的架构设计定义,关键因素就是业务变化。显然这个时代的业务变化是很快的,甚至很多业务主动在变,不变则亡是很多行业目前的共识。变化速度给架构设计带来了很大挑战,一个移动APP可能需要在一周内上线,然而为了支撑这个移动APP的后台服务,平台发布窗口是每两个月一次。这样的不匹配在IT领域里是随处可见的现实,我们习惯性地认为后台天然就很重因此很慢,只可能在牺牲质量的情况下满足这样的速度。

然而事实上这样的健壮架构确实是存在的,看看身边现在无处不在的互联网,又有哪一个企业的架构比之复杂呢。互联网系统的组件是一个个网站,每个网站完成着自己的业务功能更新,从新闻发布到在线聊天。而各个站点又是紧密互联的,聊天网站可能把新闻网站拿到的信息实时推送给在线的用户。每个网站都是独立的小单元,面向互联网用户提供着一定的业务服务。好的网站也根据用户的反馈在不停升级和变化,但这样的变化并不影响用户使用其它的网站。

从互联网架构我们可以学到什么呢?从架构设计角度我认为以下三点是关键。

  1. 让我们的组件划分尽量靠近变化的原点,对于互联网来说就是用户和业务,这样的划分能够让我们将变化“隔离”在一定的范围(组件)内,从而帮助我们有效减少改变点。
  2. 组件之间能够互相调用,但彼此之间不应该有强依赖,即各自完成的业务是相对独立的,不会因为一方掉线而牵连另外一方,比如新闻网站挂掉了,聊天网站应该继续正常提供服务,可能提示用户暂时无法提供新闻信息而已。
  3. 组件在业务上是鼓励复用的,正是这样的复用才成就了今天的互联网,我们不会每个网站都去实现一个强大的搜索引擎。而被“复用”最多的网站显然会受到追捧,成为明星业务。当然架构上这样的网站必然是健壮的。

上面的三点毫无疑问都指向了业务,从业务出发、面向业务变化是我们现代架构设计成功的关键

架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。

这种响应力体现在新需求(变化)的实现速度上,也体现在我们组件的复用上,在实现过程中现有架构和代码变化点的数量也是技术人员能够切身体会到的。面对日新月异的数字化时代,组织的整体关注点都应该集中到变化的原点,即业务上,而架构应该服务于这种组织模式,让这样的模式落地变得自然。

对比之前的传统SOA架构,这个思路的变化是本质性的。类似工业总线(ESB)这样的组件化其实是面向技术的,希望通过技术平台的灵活性来解决业务变化的多样性。虽然短时间能够收到一定的成效,长期看必然把自身做成瓶颈,因为所有业务的变化最后都堆积到了这个技术组件来解决。这也回答了为什么实施了传统SOA架构的企业最后都发现响应速度其实并没有提升起来。

面向业务变化而架构就要求首先理解业务的核心问题,即有针对性地进行关注点分离来找到相对内聚的业务活动形成子问题域。子问题域内部是相对稳定的,即未来的变化频率不会很高,而子问题边界是很容易变化的,比如在一个物流系统中:计算货物从A地到B地的路径是相对固定的,计算包裹的体积及归类也是相对固定的,但根据包裹的体积优化路径却经常会根据业务条件而变化。

(子问题域的划分)

面对业务的变化也要求我们的架构必须是演进的,因为业务的变化点也会随着时间推移发生着变化。这意味着在一款较长生命周期的软件产品中,不会出现类似ESB这样的重型组件,相反的我们追求的是一些面向业务服务的轻量级组件,它们的持续演进也会造成老组件的合并,新组件的重新拆分。当然这也成了现代微服务架构成功的基础条件之一。

打造架构响应力的方法

如果认同了上述现代架构的真正意义,大家一定会问怎么才能打造这样的高响应力架构呢?

领域驱动设计方法DDD(Domain Driven Design)为我们提供了很好的切入点。这个2003年就总结出来的方法终于在10多年后重新走入了架构师的视野,而这一次大家已经意识到了这种方法在这个快速变化时代的重要性。DDD通过以下两个模式去有效解决了文章开始提到的两大痛点:

  1. 让团队中各个角色(从业务到开发测试)都能够采用统一的架构语言,从而避免组件划分过程中的边界错位。
  2. 让业务架构和系统架构形成绑定关系,从而建立针对业务变化的高响应力架构。

这两点是DDD的核心,也是为什么时下全球架构圈在进一步向DDD这个方向靠拢的原因。DDD明确了业务和系统架构上的绑定关系,并提供了一套元语言来帮助各个角色有效交流架构设计。

(DDD的基本方法)

在战略层面,DDD非常强调针对业务问题的分析和分解,通过识别核心问题域来降低分析的复杂度。在战术层面,DDD强调通过识别问题域里的不同业务上下文来进行面向业务需求的组件化。最后在实现层面利用成熟的技术模式屏蔽掉技术细节的复杂度。

在这里我们也希望通过第一届DDD China建立起一个架构设计人员的交流平台。期待更多的中国技术人员能够通过这个平台和世界一流架构大师们建立起沟通的渠道,不仅在战略层面,也在战术层面和所有人一起分享讨论关于DDD的一切。


更多精彩洞见,请关注微信公众号:思特沃克

Share