5 ms·

If there were a way to produce bounded context boundaries by following a general pattern / algorithm, what would that be? I fail to see how they can be created

If there were a way to produce bounded context boundaries by following a general pattern / algorithm, what would that be? I fail to see how they can be created usefully without lot's of conversations with domain experts plus elbow grease. It's the part of software that remains entirely art and not science. Why is that a bad thing?

pydry 5y ago
My impression was that it would: * Try to mininimize the overlap between bounded contexts - loosely coupling domain models. * Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts. I tend to find any process that defaults to "have more conversations/interactions" defaults to wheel spinning without some sort of specific plan about what those interactions would entail.
- amw-zero 5y ago
  > Try to mininimize the overlap between bounded contexts - loosely coupling domain models. What if this doesn't lead to a more accurate representation of the domain? What if two contexts are just coupled in the business, for good reasons? > Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context? It's like, building any system involving many actors and actions is hard, that has nothing to do with software. We're just digitizing the same patterns and behaviors that people have used to run companies for hundreds of years. People want a playbook to be followed to arrive at a "perfect" domain model or architecture. I'm sorry, that sounds pretty farfetched to me. It reminds me of how we first started thinking about computability theory, when David Hilbert proposed that we should be able to devise an algorithm that could decide the truth or falsity of any logical statement (the Entscheidungsproblem). Hilbert was one of the smartest mathematicians to ever live, and he was very confident that this could be done. Well, Alan Turing, Kurt Gödel, and Alonzo Church (not slouches in their own right) all smashed that idea with various proofs. The truth can often be counterintuitive. I am sorry that the world is complex, I also wish it weren't so.
  - corpMaverick 5y ago
    > This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context? This is a very important question. I will bite and give a guidance because no one is willing to give advice here. If you development team grows over 10 SE. Then you need to split it. So your bounded context has a complete team on it becoming experts in the subject as well as experts in the software implementation. Each team should be able to work independently of other teams.
    - amw-zero 5y ago
      Forming your bounded contexts based on technical complexity and team configuration is certainly not advocated by DDD. Is "larger than 10 software engineers" a rule that domain experts would suggest? Would that be in the ubiquitous language?
      - pydry 5y ago
        How exactly does DDD advocate forming bounded contexts? I ask because only ever heard personal opinions in answer to this question. I researched it heavily and found nothing. As far as I can tell it doesnt.
        amw-zero 5y ago
        I've been replying to you in other threads. There is no answer to this question, it is an art. I understand that it's frustrating, but that doesn't make it any less true. As far as what the goal of the art is - the goal is to avoid linguistic and semantic ambiguities in the ubiquitous language. There is even a section entitled "Recognizing Splinters Within a Bounded Context" where specific examples are given: * duplicate concepts * false cognates If you have truly duplicate concepts across contexts, this is a symptom of the lines not properly being drawn, and perhaps a new, shared context is missing. False cognates are the bread and butter of bounded contexts though - these occur when two areas of a business use the same exact word for something, but they mean slightly different things _depending on the business context_. The example in the book given is the notion of a "Charge," which customer invoicing and bill payment departments might both use. But each department only cares about certain pieces of data of a charge, so if one "Charge" model were created, it would be more complicated because it had to worry about all the different ways that the teams use it. And even worse, sometimes they are used in _conflicting ways_. That is a semantic collision, creating ambiguity in the model. This is what a bounded context is meant to address. Each department gets its own model, each with its own version of Charge. The code and data is fit for the specific business purpose it's serving, instead of having a one-size-fits all model that gets the job done, but is more complicated to use in all contexts. Honestly curious, have you read the book? I still don't think it will give you what you're looking for in terms of a prescriptive formula for "doing DDD right," but there's quite a bit of guidance in there.

pydry 5y ago

My impression was that it would: * Try to mininimize the overlap between bounded contexts - loosely coupling domain models. * Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts. I tend to find any process that defaults to "have more conversations/interactions" defaults to wheel spinning without some sort of specific plan about what those interactions would entail.

amw-zero 5y ago
> Try to mininimize the overlap between bounded contexts - loosely coupling domain models. What if this doesn't lead to a more accurate representation of the domain? What if two contexts are just coupled in the business, for good reasons? > Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context? It's like, building any system involving many actors and actions is hard, that has nothing to do with software. We're just digitizing the same patterns and behaviors that people have used to run companies for hundreds of years. People want a playbook to be followed to arrive at a "perfect" domain model or architecture. I'm sorry, that sounds pretty farfetched to me. It reminds me of how we first started thinking about computability theory, when David Hilbert proposed that we should be able to devise an algorithm that could decide the truth or falsity of any logical statement (the Entscheidungsproblem). Hilbert was one of the smartest mathematicians to ever live, and he was very confident that this could be done. Well, Alan Turing, Kurt Gödel, and Alonzo Church (not slouches in their own right) all smashed that idea with various proofs. The truth can often be counterintuitive. I am sorry that the world is complex, I also wish it weren't so.
- corpMaverick 5y ago
  > This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context? This is a very important question. I will bite and give a guidance because no one is willing to give advice here. If you development team grows over 10 SE. Then you need to split it. So your bounded context has a complete team on it becoming experts in the subject as well as experts in the software implementation. Each team should be able to work independently of other teams.
  - amw-zero 5y ago
    Forming your bounded contexts based on technical complexity and team configuration is certainly not advocated by DDD. Is "larger than 10 software engineers" a rule that domain experts would suggest? Would that be in the ubiquitous language?
    - pydry 5y ago
      How exactly does DDD advocate forming bounded contexts? I ask because only ever heard personal opinions in answer to this question. I researched it heavily and found nothing. As far as I can tell it doesnt.
      - amw-zero 5y ago
        I've been replying to you in other threads. There is no answer to this question, it is an art. I understand that it's frustrating, but that doesn't make it any less true. As far as what the goal of the art is - the goal is to avoid linguistic and semantic ambiguities in the ubiquitous language. There is even a section entitled "Recognizing Splinters Within a Bounded Context" where specific examples are given: * duplicate concepts * false cognates If you have truly duplicate concepts across contexts, this is a symptom of the lines not properly being drawn, and perhaps a new, shared context is missing. False cognates are the bread and butter of bounded contexts though - these occur when two areas of a business use the same exact word for something, but they mean slightly different things _depending on the business context_. The example in the book given is the notion of a "Charge," which customer invoicing and bill payment departments might both use. But each department only cares about certain pieces of data of a charge, so if one "Charge" model were created, it would be more complicated because it had to worry about all the different ways that the teams use it. And even worse, sometimes they are used in _conflicting ways_. That is a semantic collision, creating ambiguity in the model. This is what a bounded context is meant to address. Each department gets its own model, each with its own version of Charge. The code and data is fit for the specific business purpose it's serving, instead of having a one-size-fits all model that gets the job done, but is more complicated to use in all contexts. Honestly curious, have you read the book? I still don't think it will give you what you're looking for in terms of a prescriptive formula for "doing DDD right," but there's quite a bit of guidance in there.