When you start with APIs, you really have to have a very good grasp of what that API’s users will need. You typically don’t. Instead, you try to come up with things that will “obviously” be re-usable, and end up with things that are not even useful.
My assumption is we need to get everyone’s conceptual model out of their heads and into some coherent form. If you think adding yours to the mix could help, feel free to just do it.
Apologies, I just wanted to start with a small round of people and ask them who they want to include so we don’t end up with an unmanageable size. You’re welcome to join.
I believe we had that discussion several years ago, Udi :) Yes, that’s a difference, and pulling the deployment view into early architectural discussions is in fact intentional.
Great inspiration goes to one of your GOTO (or QCon?) talks from several years ago, BTW
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.
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.)
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.
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.