《领域驱动设计》作者Eric Evans在Explore DDD主题演讲会上呼吁与会者积极参与改进用于复杂系统的建模和设计语言。Evans 承认，DDD 中使用的一些基本术语（例如有界上下文）经常被误解。其他短语（如“遗留软件”）由于个人偏见会导致在架构系统时效率低下。在提出了几个更清晰的语言选择之后，他希望其他人能够发表不同的观点。只有借助积极的社区和富有成效的辩论，我们才能让 DDD 成为“一个真正有生命力的思想体”。
Evans 认为，在他的书出版 15 年之后，也就是现在，可能是时候回到最基础的原则，并有意识地向前迈出新的一步。其中的一个关注点是澄清有界上下文、子域和组织这三个概念所导致的混淆。在很多情况下，一个有界上下文对应一个组织或团队，也可以对应一个子域。然而，大公司通常会进行重组，导致业务流程和职责发生变更。在发生这些重组时，软件并不会以同样的方式发生改变，因此功能管理变得不清晰。之前由一个组织承担的职责，现在需要两个组织通过协作来定义需求和优先级。Evans 拿这个与双人三腿赛跑作对比，要想在双人三腿赛跑中获胜，参与者需要在速度和协调性之间找到平衡。一个不协调的团队会输掉比赛，但一个协调的很好但速度慢的团队也不会赢。
他承认，近来 DDD 的复苏在很大程度上是由于微服务的兴起，因此他认为这是进行富有成效的对话的大好机会。Evans 反驳了人们只是在追随“微服务潮流”的观点，他认为，“微服务是打破障碍的攻城槌，在混乱中寻找机遇”。
“微服务是有边界的上下文”这句话经常被提及，但这种说法过于简单化了。Evans 描述了微服务系统中的四种上下文类型:
在服务内部；
服务API；
服务集群；
服务之间的交互。
随着上下文类型的增加，我们也需要从狭窄和集中式的思维转向更为广阔的架构视角。如果每个微服务都可以独立定义一种用于跨系统通信的语言和消息，而不全盘考虑架构，那一定会出现混乱。
Evans 还想要重新定义什么是遗留系统，并让人们能够更有效地讨论它们。Evans 拿花园作为比喻，一个新花园有很好的秩序感，但夏末的花园才有“丰富的成熟度”，这就是花园的价值所在。类似地，开发人员和架构师应该以创建秩序为目标播下种子，但也要欣赏成熟的系统中存在的丰富的混沌。
除了“遗留系统”，Evans 提议可以用更多其他新的方式来分类和描述“成熟上下文”。在应用 DDD 时，需要理出系统的上下文和上下文之间的关系。确定成熟的上下文可以处理的枯燥职责，帮你与总是从头开始的人性本能作斗争，就像一个成熟的花园已经富有成效一样。Evans 指出，反腐败层是双向的，它们保护新代码不受遗留系统的影响，同时还会让遗留系统不受新代码的影响。
在处理被称为大泥球的系统的代码时，需要注意的是，并不是系统的所有部分都设计得很好。一旦系统变得足够大，你就无法回到整洁的世界。相反，我们的目标应该是从良好的边界和隔离上下文从获得好处。
原文链接：
Eric Evans Wants to Improve the Language of DDD
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论