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
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
But I use the term “monolith” half-jokingly when I say you should build many of them. I still think our views align more than you seem to think now. In 90% of the cases, 1 SCS = 1 BC is what I’d recommend.

Apr 12, 2020 · 8:44 PM UTC

2
2
I think our thoughts align very closely. It's just that I didn't know that SCS could be a monolith (even if less common) until half way through this thread. I will read Martin's post; unfamiliar with his reasoning. However, my guess he is not using multiple BCs in the monolith.
1
I see now that's your post on Martin's site. I note your concerns are the ones ^^^ I predicted, that if you start with a monolith your code will become coupled early. You see microservices as preventing that, and it would (ie the Aggregate rule of thumb to reference by id only).
1
(And I can’t rule out I’m missing some of the finer points of DDD terminology)
1