DDD與企業架構之間的共識

Question

在文獻中（博客，文章，關於企業架構的書籍......），似乎EA中有一個真正（且獨有）的SOA設備。如果我們認爲DDD和SOA共享通用體系結構原則但在許多其他方面有所不同，那麼在EA學科中DDD的位置是什麼？

Answer 1

DDD和SOA在一起發揮得很好。通常服務邊界與您有界的上下文匹配。您使用SOA來設計跨上下文的通信，並且它都可以工作。 EA並沒有深入瞭解你如何開發你的「服務」，但DDD可以幫助你。

Answer 2

對我來說，DDD最大的好處就是它可以讓你在分析業務領域時做好工作。

對領域的瞭解絕不是一件壞事，當然這個說法也適用於SOA。更重要的是，如果您爲大多數實體構建通用數據模型，則可以提高互操作性，因爲您可以構建更多標準化服務，因此您將避免數據映射和轉換。當你做服務組合和/或編排時，常見類型往往成爲必須。因此，如果您事先投入更多工作，那麼在您的服務和庫存得以治理時，您將會有更輕鬆的時間。

正如Alexey已經指出的，DDD和SOA不會互相影響和協同工作。

Answer 3

Thomas Erl在他的書「SOA Design Patterns」中描述了軟件如何最終由技術，平臺或資源相關的架構元素組成。他接着解釋了面向服務的技術架構的重要性和它的四種常見類型，其中有：

1. 服務架構
2. 服務組合架構
3. 服務清單架構
4. 面向服務的企業架構

就技術架構而言，沒有提及應該如何實現服務（DDD或其他）。它只強調它們的存在，它們的可組合性和邊界。

域驅動設計，涵蓋了軟件組件設計的「如何」。這正是書中所發生的。當敘述擺到設計模式時，像域名清單和實體抽象這樣的主題就出現了。因此，只要設計方法符合SOA（業務驅動，供應商中立，以企業爲中心，以組合爲中心）和其設計原則（標準化服務合同，服務鬆散耦合，服務抽象，服務可重​​用性等四個特徵）服務自主性，服務無狀態，服務可發現性和服務可組合性），在我看來，DDD可以安全地用於設計和實現軟件及其服務。