我已經開始學習DDD的原則，並且我正在試圖理解有界上下文的概念。特別是，你如何決定它有多大（或小）？是的，我知道，儘可能小和必要的大（根據沃恩弗農）。有界的上下文的大小
比方說，我要建模一個博客。然後，我可以說，有3個有限的背景涉及：1）頭版（以最近的文章爲特色，沒有評論顯示）2）討論（單篇文章包括評論）3）文章作者（撰寫文章的地方）。
但是，這種感覺不正確（無處不在的語言對所有人來說都是一樣的），看起來好像我是從前端觀點來的，並且仍然在視圖模型或一些東西。
任何人都可以請指點我正確的方向嗎？
嘗試看看從不同的角度整個域，作爲文章的編輯，你可能會使用諸如創建文章草稿，發表文章等句子，作爲閱讀文章並對其發表評論的文章。除了構建您的領域語言，您還將識別實體及其行爲，其中一些將僅以一種視角出現，一些將出現在兩者中，但您將通過其行爲區分它們。您的域語言向您展示了每個視角的邊界，並將您實現爲有界的上下文。
是的，這是主意。評論在撰寫文章時沒有任何意義，在作曲家中添加圖片與此類似，因爲它在頭版上沒有任何意義。 –
我實際上想出了組合BC的這些動作：UpdateTitle，UpdateContent，Publish和Retract。相反，我得到了BC省討論區的增補評論。 –
博客不是使用多重有界上下文的好例子。這不是一個真正的「足夠大」的軟件示例來保證它們的定義。 DDD & BC的確針對大型/複雜的進取軟件系統。
就像你說的那樣，聚合在你的3個例子中總是有相同的含義。
我給在前面的回答，我希望限界上下文的這個例子說明了卑詩省以及何時使用它們：Bounded Contexts and Aggregate Roots
只是讓我的腳溼了，因爲我在建設網站的過程中，我想爲什麼不應用DDD在這裏試驗。我完全意識到這是一種矯枉過正，但我不介意如果這樣做，我可以得到一些關於DDD的經驗。 –
到目前爲止，我通過子域讀取的最佳示例如下。
只要檢查實際的公司！參與業務流程的每個部門都可以擁有自己的子域。在一個理想的世界中，每個子域在你的實現中都有自己的有限上下文。你應該問自己公司是否需要一個新的部門來做到這一點？它真的很大嗎？
BC必須足夠大才能描述公司的一個部門。一個典型的例子是一個網上商店，你有一個購物核心域和發票，交付和存儲子域。擁有多租戶和多方面 - 就像之前所描述的答案 - 是不夠的。一個作者和一些讀者的博客不需要多個部門，所以你可以用一個有界的上下文來解決這個問題。如果您認爲在有界的上下文中具有中等大小的結構，則可以在有界的上下文中包含多個模塊。
我不是這個話題的專家，但我認爲你是對的。像文章和評論這樣的詞總是具有相同的含義，所以它是一個單一的有界的上下文，這並不複雜，它只是簡單的CRUD。 – inf3rno
在這種情況下它可能不值得，但BCs會從行爲和概念中出現。例如，您的博客可能有一個管理上下文，允許超級管理員禁止帳戶並執行其他管理任務。這些並不是博客的核心領域的一部分，並可能證明新的BC。 – plalx
@plalx好點，馬上讓我想起弗農書中的例子。 –