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
Multiple Bounded Contexts in one SCS is probably more like a monolith, or definitely so. If SCS is meant for that then I suggest it be more clearly stated on a single slide and in the docs. You might even state:
SCS can be:
- Course-Grained Microservice
- Multi-Model Monolith
1
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.)
1
1
No, because SCS is @INNOQ definition. It should be what you think it is.
I referred @polarbit29 (and others) to SCS thinking it is limited to defining BC-sized microservices such as has been in discussion the past few days. I didn't think it defines monoliths as well.
1
This is not a problem IMO, but I think it needs to stand out clearly using the word *monolith* as one option in a range.
Yes, I tell teams to start with a modular monolith of multiple BCs. If your aim is separate microservices then you extract BCs after the monolith works.
1
1
4
As a matter of fact, that’s one part I disagree with (at least to a certain degree): martinfowler.com/articles/do…
1
1
(And I can’t rule out I’m missing some of the finer points of DDD terminology)
Apr 12, 2020 · 8:45 PM UTC
1
