0

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

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!

Marco
  • 2,453
  • 3
  • 25
  • 35
  • 1
    It often boils down to the people doing the work. You do not want to create artificial bounded contexts. Look at the job people do. Do every job implies working with annoucements, feedback, documents and reimbursements? I'm pretty sure reimbursements have little to do with annoucements. – plalx Aug 13 '16 at 03:55

1 Answers1

2

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.

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.

tomliversidge
  • 2,339
  • 1
  • 15
  • 15
  • the only thing really is a user is an "owner" when talking about documents and a "submitter" when talking about announcements. not sure if that means i should break them up. – Marco Aug 12 '16 at 15:58
  • "It might be that you have a single bounded context with many sub-domains" Bounded contexts should ideally align 1 to 1 with sub-domains. For pragmatic reasons it may be acceptable to have one BC to cover multiple sub-domains, but it is definitely not ideal. – plalx Aug 13 '16 at 03:53