识别有限的上下文 [英] Identifying Bounded Context

问题描述

每次我思考我都知道如何识别有限的上下文，因为我意识到水域仍然很模糊。这样就可以了...

everytime i think i understand how to recognize bounded context's i realize the waters are still murky. so here goes...

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

i am developing a customer portal that contains the following features: Customers, Users, Announcements, Feedback, Documents, and Reimbursements. We are just putting a pretty UI over reimbursement approvals from another system, so this one is easy to see it's another BC we integrate with. Now with the others, I'm not sure how to group these together. Would all these belong to a single BC 'Portal'? Or maybe there are seperate 'Management', 'Communications', 'Documents' BC's??

任何想法都将不胜感激！

Any thoughts would be greatly appreciated!

推荐答案

在问题空间中，通常由语言来驱动。首先，寻找您需要为解释或有关概念的讨论提供背景信息的情况。例如，如果您所拥有的东西根据您所谈论的上下文具有不同的含义。一个很好的例子是票证-如果您的情况是向演出出售票证，而服务台的情况是有人提出了问题，那么这可能意味着不同。

In the "problem space" it is usually driven by language. Start by looking for situations where you find yourself having to give a context to explanations, or discussions around the concepts. For example, if you have something that has different meaning depending on what context you are talking about. A good example is "ticket" - this could mean something different if your context is selling tickets to a show compared to a service-desk context where a ticket is an issue somebody has raised.

这通常是随着您的发展而变化的，因为您发现概念变得过大，或者您发现它们承担了过去所没有的职责。如果您发现两组不同的人对事物的理解略有不同，则这是另一个好兆头，您可能需要单独的上下文。另一个好兆头是当您开始添加布尔标志来控制事物以及可为空的字段时。

This is often something that evolves as you go, as you find concepts becoming too large, or you find them taking on responsibilities they didn't used to have. If you find two different groups of people have slightly different meanings they attach to things it is another good sign that you may need separate contexts. Another good sign is when you start adding boolean flags to control things, as well as nullable fields.

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

Customers, Users, Announcements, Feedback, Documents, and Reimbursements. Would all these belong to a single BC 'Portal'? Or maybe there are seperate 'Management', 'Communications', 'Documents' BC's??

这些内容中是否有任何概念根据您所谈论的事物而有所不同？可能是您有许多子域，每个子域都具有一个模式保持一致的有界上下文

Are there any concepts within these that are different depending on which "thing" you are talking about? It might be that you have many sub domains each with a single bounded context where the mode remains consistent

我可能会从每个子域一个上下文开始，然后拆分它们随着概念的出现而消失。

I'd probably start with a single context per sub domain, then split them out as the concepts emerge.

这篇关于识别有限的上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！