使用CQRS的DDD中的有界上下文。共享聚合/實體。可能？

https://code.google.com/p/ddd-cqrs-sample/

似乎非常完整和良好的組織。不是一個「框架」，只是一個具有非常細緻和明確的做事方式的示例項目。但是，不完整。這帶來了一些疑問。

他們善於回答你的問題。檢查他們的谷歌組在https://groups.google.com/forum/#!forum/ddd-cqrs-sample

好的。事情是他們在CRM BC中有客戶，而在CRM BC中有客戶/潛在客戶。我想我們都同意指着同一個「人」。比方說，在銷售渠道中，該人開始擔任潛在客戶，然後通過購買使他成爲客戶的東西成爲客戶。

我的問題是，爲什麼他們有三個分離的表示同一個「人」？難道不能像「共享內核聚合」？我不知道這樣的事情是否存在。這有點讓我有點在數據庫客戶端/客戶/潛在客戶數據庫中有三個表用於相同的「事情」。另外在這個例子中還不清楚（客戶關係管理沒有實施）你在不列顛哥倫比亞省之間如何溝通我閱讀他們的文檔，但我找不到任何有價值的線索。

該過程如何？假設您需要添加此主管/客戶/客戶端地址以發送訂單。你會選擇哪一個？我猜在Shipping BC的ShippingAddress？用Id指向？顧客？客戶？您是否應將地址直接添加到客戶？例如對於直郵，由於它與航運無關？

來源

2013-07-29 Pepito Fernandez

有界上下文通常由不同的團隊和不同的客戶實施（例如銷售部門和客戶關係部門）。他們都會對客戶有自己的看法，我認爲這個項目試圖通過對它們進行不同的命名來誇大這一點。

來源

2013-07-29 05:51:01 Steven

這部分我明白了。但他們有三張表據稱涉及同一個「人」。假設每個部門開始獨立修改這三個表。這不是一個混亂嗎？我想我的問題是，無論BC如何看待它，我怎樣才能使用對該人的引用？ –

BC不應該共享任何數據。你不能讓多個BC看着同一張桌子。在那種情況下，你只有一個卑詩省。BC可以發佈事件以通知其他BC有關更改，但這些事件應該包含數據，只是ID。因此，Sales可以通知CRM客戶端5232已被添加，客戶端973已成爲首選客戶。 – Steven

如果沒有共享數據，這三個表可以獨立演變。 – Steven

共享內核引入非常的 CRM和Sales BC之間的緊密耦合。

這裏是一個另類..

的CRM BC 擁有客戶。您不必在銷售BC中複製整個客戶AR。這避免了必須處理雙向同步。您可以使銷售BC中的客戶端AR通過其標識符引用CRM BC中的客戶AR，然後將特定的客戶端屬性保留在銷售BC中。這在銷售BC和下游CRM BC之間建立了銷售和CRM BC之間的順從或客戶 - 供應商關係。 CRM上下文可能會使用開放主機服務來使客戶AR可用於銷售BC。

來源

2013-07-29 08:09:36 JefClaes

不鼓勵通常跨上下文重用。共享內核可能會提供幫助的情況很少，但通常域對象（及其聚合）應保持在各自的上下文中。否則，你會引入緊耦合並失去有界上下文的主要優點之一。他們將無法獨立於彼此改變和發展。

來源

2013-07-29 17:14:31

使用CQRS的DDD中的有界上下文。共享聚合/實體。可能？

回答

相關問題