識別限界上下文

Question

每次我認爲我瞭解如何識別限界上下文的我認識的水域仍然低迷。所以這裏去...

我正在開發包含以下功能的客戶門戶：客戶，用戶，公告，信息反饋，文檔和報銷。我們只是把一個漂亮的UI放在另一個系統的報銷批准上，所以這個很容易看出它是我們整合的另一個BC。現在與其他人一起，我不確定如何將這些組合在一起。所有這些都屬於一個BC'門戶'嗎？或者也許有單獨的'管理'，'通信'，'文件'BC？

任何想法將不勝感激！

Answer 1

我可能會拍這個，但我使用兩個主要的規則：

• 限界上下文是實施的範圍，因爲「服務」
• 作爲尤迪說，對SOA通常實施 - 服務是一個技術權威對於特定的業務能力

通常，只要遵循這兩個規則就足以構建出令人滿意的結構。

另一個需要記住的事情和這裏沒有討論（在相對前一個）是卑詩省是地方無處不在的語言生活在那裏。這就是爲什麼它被稱爲有界上下文的原因，因爲如果語言生活在特定的上下文中，它只能是無處不在的。

沃恩弗農如何把它 - DDD正在開發一個有界範圍內的通用語言。

Answer 2

在「問題空間」中，它通常由語言驅動。從尋找情境開始，你必須給出解釋的上下文，或圍繞這些概念進行討論。例如，如果您根據您正在談論的背景具有不同的含義。一個很好的例子就是「門票」 - 如果您的上下文將門票賣給節目，與服務檯上下文相比，這可能意味着不同的情況，而服務檯上下文中門票是某人提出的問題。

這往往是一件演變爲你去，你找到的概念變得太大，或者你找他們承擔他們沒有使用有責任。如果你發現兩個不同的人有着不同的含義，他們會把它們附加到事物上，這是另一個好兆頭，你可能需要單獨的上下文。另一個好兆頭是當你開始添加布爾標誌來控制事物，以及可爲空的字段。

客戶，用戶，公告，反饋，文檔和報銷。所有這些都屬於一個BC'門戶'嗎？或者也許有單獨的'管理'，'通信'，'文件'BC？

這些裏面有不同的概念，根據你所說的「事物」而有所不同？這可能是你有每一個界上下文許多子域在模式保持一致

我大概每個子域的單一背景下啓動，然後分裂出來的概念出現。