领域驱动设计(Thoughtworks洞见)
上QQ阅读APP看书,第一时间看更新

端口和适配器架构——DDD好帮手

作者:周宇刚

• 本文源自2018领域驱动设计中国峰会《领域驱动设计与演进式架构专题》的Session之一,是其博客版。

• 在实践领域驱动设计时,可以挑选一些方法互为参照,端口和适配器架构概念简单,容易掌握,适合作为实践领域驱动设计的辅助方法。

大概一个月前,在做2018年领域驱动设计大会预告的时候,上一届大会的主题演讲者肖然提出这样的担忧:工具和方法似乎没有很好地解决“落地难”的挑战。

1.没有一套方法能够打遍天下,具体到采用哪一种方案,仿佛都需要增加一个定语“这取决于……”。

2.不管是在DDD原著,还是后续不少专家的书籍中,都暗示、甚至明示架构设计的终极大招还是By Experience—靠经验吃饭。

3.从战略角度的子领域划分,到战术建模层面实体、值对象的选择,最终的决策很可能不是完全“理性”的,经验这个“感性”的东西发挥着很大的作用”。

所以,推动领域驱动设计实践的方向是否应该从介绍方法转变为介绍如何累积经验?

看了这篇文章后,我放弃了之前准备的话题《CQRS和Event Sourcing,从入门到放弃》,因为可能你一年都不会遇到一个需要使用这两种方法才能解决的复杂项目。

如何快速获取经验?无非就是多练,但是练了要讨论和总结,我遇到过这样的对话,我将它称为“两小儿辩DDD”:

A:我觉得你这里不该使用实体,应该使用值对象。

B:我觉得你这个接口不是领域服务,它其实是应用服务,你这样做不DDD。

A:你的实体不应该调用Repository,你这样做也不DDD。

B:(看着我)你来评评理,我们谁说的对。

我:俺也不知道,这取决于…

这样的复盘方式效果欠佳,我建议不妨从DDD中跳出,找一种方法互为参照和检验,比如“端口和适配器架构”。