如何在.Net中正確實現共享內核（DDD）

Question

我有一個遺留應用程序，我正在重新設計，因爲這是我們所說的「泥巴球」，目前沒有分層或SOC。該團隊習慣於模塊化工作，這意味着有一個團隊在「培訓」，「工作機會」上工作，這個團隊在管理「職務規劃（軍隊）」的模塊上工作。我們有一個網站向我們的客戶展示這些領域，作爲服務門戶，一個數據庫和一些我們服務的外部應用程序。

我很好地重新設計了大部分層，除了如何正確分區域（我應該提到在這一點上，我們正在使用。NET 4.0）。我原先的想法是，由於他們工作的方式，這些是有限的背景，他們確實有不同的用戶組，但我認爲現實情況是，使用這個站點的人可能並且一次使用很多區域。當然，有些團體只使用一種服務，但大量使用一種服務。該網站的目標是「成員」的一站式管理。在模塊之間，我們有模塊特有的類，然後我們有一些共享類，例如，成員的概念是已知的，並被所有模塊使用。會員實際上是一個核心概念，該網站通過一次跟蹤所有這些領域的會員信息來增加價值。這基本上就是它，系統中的一些緊密相關但獨立的區域和共享區域。我希望這足以清楚地回答我的問題。

我在想，即使這些共享內核不是有界的上下文，對於公共實體和共享域接口（如通用存儲庫接口）仍然會有共享內核。將所有常用代碼（通用存儲庫，核心域模型，共享內核等）放入相同的名稱空間或名稱空間層次結構中是否明智？是否應該將該名稱空間分離到它自己的程序集中？同樣，我是否會將每個領域（「培訓」，「機會」......）分解到他們自己的程序集中，還是將它們全部集中在一個程序集中並通過命名空間在邏輯上進行分區會更好？一方面，查看模塊的物理分區更容易一些，但我擔心兩個模塊需要共同解決問題的情況。他們如何溝通並保持非循環（通過我猜測的應用層服務）。

所以（選項摘要）：

Domain.Model（DLL） - Domain.Model.Core - 內核（共享實體和核心域模型） - RepositoryFramework - 等.. - Domain.Model.Training - Domain.Model.Opportunities ...

或

Domain.Model.Core

Domain.Model.Training（DLL）

Domain.Model.Opportunities（DLL） （怎麼辦的培訓和機會一起工作？）

非常感謝您的寶貴時間，

Answer 1

在物理佈局的情況下，我會把一切（整個域模型）放在一個程序集中。使用單獨的程序集不會給您帶來任何好處，但它會使事情變得複雜並增加編譯時間。另一方面，如果存在一些開發人員使用不適當的類（屬於其他模塊/上下文的類）的風險，將邏輯拆分爲常見程序集（核心域，共享內核）和特定於每個模塊/上下文的組件。

在邏輯佈局（名稱空間）的情況下，我會給每個部分一個單獨的名稱空間（例如DomainModel.Core，DomainModel.Training）。有時候更明智的做法是將每個Aggregate放入其自己的名稱空間中。它可以防止意外越過聚合邊界，因爲它需要單獨的「使用」指令。

希望是有道理的。