领域驱动设计的DDD与ddd - nick

21-11-13 banq

Eric Evans在 2000 年代初撰写领域驱动设计 (DDD) 一书的原因是为了鼓励那个时代更好的领域驱动设计 (ddd) 实践。设计由数据模型驱动,技术和业务同事之间的协作不足。DDD 这本书反映了 Eric 当时的观点和观点,即他如何将软件开发世界推向更多领域驱动而不是数据模型驱动。他使用有界上下文、无处不在的语言和聚合等名称来真正强调这些信念。

这些是Domain-Driven Design (DDD),而不是domain-driven design (ddd) ;

 

Mathias Verraes对 DDD定义是思考什么是domain-driven design (ddd) 的起点:

DDD 是一门 [软件] 设计学科,您可以在其中
掌握领域
- 就一种语言达成一致
- 在共享模型中表达
- 接受复杂性
- 在上下文中分离模型
......并不断进化它们

 

如果您考虑一下,这几乎适用于所有软件开发项目。我们都在不同程度上做所有这些事情。就像编写单元测试是一项技能一样,ddd 也是一项我们应该努力并努力提高的技能。

我个人将 domain-driven design (ddd) 定义为:

  • 识别域中未满足的用户需求
  • 获得该领域的专业知识
  • 设计新功能以满足未满足的需求
  • 为新功能的每个部分创建专门的模型
  • 根据领域术语为每个模型建立专门的语言
  • 在代码中实现模型

您可以在没有协作、进化和专注于战略领域的情况下进行 ddd,但除非你一个人工作,否则它不会有效。

Mathias 还添加了另一个关于 ddd 和 DDD 规模级别的精彩观点:

它从微观层面的代码和设计模式,到模型及其语言,到模型之间的通信和关系,再到对系统系统的大规模推理来考虑设计。

 

DDD与ddd区分的意义?

首先,我认为 DDD 不应与 ddd 分开或以任何方式放弃。对于初学者来说,它是一个很好的工具包,提供了开始使用 ddd 的指南和构建块,并有助于培养 ddd 思维方式。我也认为 DDD 对于想要接受它的有经验的团队来说是一个不错的选择。

但是,我确实认为我们应该能够在不暗示 DDD 的情况下谈论 ddd。我们可以谈论“做 ddd”,而无需使用 Bounded Context、Ubiquitous Language 和 Aggregate 等DDD专业术语。

更进一步,我认为应该有空间让其他固执的 ddd 哲学与 DDD 并存,例如Uber的面向领域的微服务

我相信 DDD 社区应该接受所有形式的 ddd。我们可以尊重 DDD 的传统,同时仍然允许激进的新想法并包容不熟悉 DDD 的人。公平地说,DDD/ddd 社区已经很棒并且正在做这些事情。

 

作者:Nick Tune,技术负责人 | 社会技术架构师 | 持续交付| 组织设计

1
猜你喜欢