Briefly
- System (also) has too many meanings. I've concluded that N deployed independent Bounded Contexts are together a System. However, I am pretty sure that Donella H. Meadows would agree that an SCS is indeed a System.
1
1
2
- In the SCS infodeck is a statement that within a SCS there are potentially multiple domains and a core domain. I assume it means "models." Although this ok with DDD, I think that it is spelled "Core Domain" and means differentiating value. I think of Core Domain == SCS.
2
2
In other words, a Core Domain is not just the most important model in any ol' Bounded Context.
Also we should strive for 1:1 model and Bounded Context.
For example, a Supporting Subdomain could possibly have that situation, but it is definitely not a DDD "Core Domain."
1
2
This is, of course, in terms of DDD. Perhaps you didn't have DDD precisely in mind when you codified SCS. So it's understandable that you could have the case of multiple models and the most important model in one SCS.
2
1
Thank you. I’ll leave the discussion of DDD terminology to one of my more knowledgeable colleagues. Personally, I like an SCS to be the physical instantiation of, or wrapper around, one bounded context, including its interfaces to the outside world.
1
1
From my limited understanding, the core domain (in DDD terms) could be spread across multiple SCSs, but doesn’t have to be
1
1
To me multiple SCS for on Core Domain sounds like tiny microservices. But the infodeck basically says the opposite: SCS == M models 1 Core.
1
2
Multiple SCS for one core domain would in my view be an exception, not the rule. I don’t object to multiple BCs within one SCS if the resulting system is still maintainable by one team.
1
So in your view, it would be better if an SCS always contained exactly one BC?
(And BTW I agree that each SCS is a (possibly modular) monolith. Monoliths are awesome, so let’s build many of them.)
Apr 12, 2020 · 5:45 PM UTC
1
1