This is my interpretation of what a Bounded Context means: a bounded context restricts (or BOUNDS) the interpretation of the important terms in the domain (hence providing a CONTEXT), thereby making one model internal to that boundary consistent.
This is core to why some members of the #DDDesign community refer to the Bounded Context as a linguistic boundary: by restricting the interpretation of the domain-specific terms to one consistent meaning it thereby defines one dialect of the Ubuiquitous Language
The model that the Bounded Context contains, can be implemented in code (or not!), but importantly, this boundary will be visible somewhere. The explicit nature of the boundary in our system is a key aspect of its ability to provide utility.
Another point important to this definition is that this allows for a BC to have no code whatsoever (and that's a good thing)! The model could very well be implemented as processes (as in a sequence of steps) that people follow to achieve a desired business goal.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@cakper Ooh, this is an amazing topic for discussion.
@cakper Basically, my position on this is: 1. Put time for up-front collaborative analysis to get to you a good starting point 2. Decompose to responsibilities considering 👆and coupling 3. Be aware of feedback loops and shorten them as much as possible
1/X
@cakper 4. Funilly enough, ime, the best way to respond to change is _not_ to prepare for it through abstractions \ structural decomposition etc, but to encapsulate behind stable behavioural contracts and do the simplest implementation behind those contracts
2/X