領域驅動設計的DDD與ddd - nick

banq發表於2021-11-13

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，技術負責人 | 社會技術架構師 | 持續交付| 組織設計

相關文章