转载

DDD提出者Eric Evans承认不足，希望DDD语言不断改进 - infoQ

领域驱动设计的作者埃里克·埃文斯（Eric Evans）在前几天 Explore DDD 上的主题演讲中，邀请听众积极参与改进在建模和设计复杂系统时使用的语言。

埃文斯（Evans）承认，DDD中使用的一些基本术语行话，如“有界上下文”常常被误解。由于个人的偏见，其他短语（例如“遗留软件”）也会造成系统产生无生产力的结构。

在关于如何提出一些更清晰的语言建议时，他欢迎所有人都可以不同意他的意见（banq注：不能因为不同意他的观点被定位为邪教，例如聚合一词很多人认为不合适）。

只有通过一个活跃的社区，在富有争议的辩论中，我们才能真正实现DDD成为一个真实，生动的思想体系的目标。

埃文斯（Evans）认为，在他的书出版15年后的今天，也许是时候采取一些措施来回归基本面，然后有意识地迈出新的步伐了。重点步骤之一应该就是：解决因为有界上下文，子域和组织的共同对齐而引起的混乱。(banq注：子域属于问题空间边界内，组织针对问题空间会提出解决方案，有界上下文属于解决方案空间内，问题、人组织和解决方案这三个空间的概念如何映射对应？是当前DDD最大问题)

在许多情况下，一个有界上下文可以与组织或团队保持一致，也可以与子域保持一致。但是，大型公司以重组而闻名，导致业务流程和职责的变化。当这些重组发生时，软件不会以与重组前相同的方式进行更改，因此功能的管理方式变得不清楚。以前一个组织的职责现在可能需要两个小组协作才能以定义需求和优先级。

埃文斯（Evans）将这与三足式比赛进行了比较（三个人将腿帮在一起的比赛），在三足式比赛中，成功需要参与者在速度和协调性之间找到平衡。不协调的团队将会跌倒，而协调良好但行动缓慢的团队将无法获胜。

他承认DDD最近的复兴是由于微服务的兴起而引起的，他认为这是开始富有成效的对话的绝佳机会。埃文斯认为，有些人只是“跳上了微服务潮流”，“微服务是打破障碍的重量战斗之路，要看混乱中的机会。”

微服务和DDD的关系，经常重复的一个普遍的概念是：“微服务是有界上下文”，这是一种过分简化。Evans描述了微服务系统中的四种有界上下文类型：

服务内部（的上下文）
服务的API（的上下文）
服务集群（的上下文）
服务之间的交互（的上下文）

随着上下文范围在此列表中的增加，思考的类型必须从狭隘和专注转变为广泛的体系结构观点。如果每个微服务都只是彼此各自定义一套自己的独特的通用语言，然后再使用消息在整个系统中进行微服务之间通信，而没有架构上的统一思考，那将导致彻底的混乱。（banq注：有界上下文定义了自己一套独特的通用统一语言，但是微服务就是有界上下文，因此微服务其实也就是定义了一套自己独特的语言，从业务术语行话到计算机语言都可能不同，但是这种不同必须能够相互集成在一起，这需要架构上设计）

Evans还想重新设计人们谈论旧系统的方式，并找到以更有效率的方式进行讨论的方法。埃文斯经常使用花园的比喻。新建的花园具有很好的秩序感，但是夏末花园（旧系统）具有“成熟度”，这就是发现花园的价值所在。同样，开发人员和架构师应以建立秩序为目标播种种子，但也应欣赏成熟系统中存在的混乱丰富性。

埃文斯（Evans）提出不仅仅是针对广义的“传统旧系统”，还提出了新的方法来对“成熟的环境”进行分类和描述。使用DDD技术，应该绘制出成熟系统的上下文，并绘制上下文之间的关系。通过识别成熟环境已经处理的无聊的例行职责，可以帮助从始至终地对抗本能，就像成熟的花园已经具有生产力一样。埃文斯指出，反腐败层是双向的；反腐败层是双向的。它们保护旧系统中的新代码，并且还使旧系统不受新代码的影响。

当使用可能被描述为“泥泞大球”的代码时，重要的是要记住，并非系统的所有部分都会经过精心设计。一旦系统足够大，您将无法回到整洁的世界。取而代之的是，争取在良好边界下实现的利益，并隔离整洁的环境。

原文 https://www.jdon.com/53161

正文到此结束