识别限界上下文

Question

每次我认为我了解如何识别限界上下文的我认识的水域仍然低迷。所以这里去...

我正在开发包含以下功能的客户门户：客户，用户，公告，信息反馈，文档和报销。我们只是把一个漂亮的UI放在另一个系统的报销批准上，所以这个很容易看出它是我们整合的另一个BC。现在与其他人一起，我不确定如何将这些组合在一起。所有这些都属于一个BC'门户'吗？或者也许有单独的'管理'，'通信'，'文件'BC？

任何想法将不胜感激！

Answer 1

我可能会拍这个，但我使用两个主要的规则：

• 限界上下文是实施的范围，因为“服务”
• 作为尤迪说，对SOA通常实施 - 服务是一个技术权威对于特定的业务能力

通常，只要遵循这两个规则就足以构建出令人满意的结构。

另一个需要记住的事情和这里没有讨论（在相对前一个）是卑诗省是地方无处不在的语言生活在那里。这就是为什么它被称为有界上下文的原因，因为如果语言生活在特定的上下文中，它只能是无处不在的。

沃恩弗农如何把它 - DDD正在开发一个有界范围内的通用语言。

Answer 2

在“问题空间”中，它通常由语言驱动。从寻找情境开始，你必须给出解释的上下文，或围绕这些概念进行讨论。例如，如果您根据您正在谈论的背景具有不同的含义。一个很好的例子就是“门票” - 如果您的上下文将门票卖给节目，与服务台上下文相比，这可能意味着不同的情况，而服务台上下文中门票是某人提出的问题。

这往往是一件演变为你去，你找到的概念变得太大，或者你找他们承担他们没有使用有责任。如果你发现两个不同的人有着不同的含义，他们会把它们附加到事物上，这是另一个好兆头，你可能需要单独的上下文。另一个好兆头是当你开始添加布尔标志来控制事物，以及可为空的字段。

客户，用户，公告，反馈，文档和报销。所有这些都属于一个BC'门户'吗？或者也许有单独的'管理'，'通信'，'文件'BC？

这些里面有不同的概念，根据你所说的“事物”而有所不同？这可能是你有每一个界上下文许多子域在模式保持一致

我大概每个子域的单一背景下启动，然后分裂出来的概念出现。