CEO/Principal Consultant at INNOQ, he/him, software architect, RESTafarian, conference tourist. Works at innoq.com. Fediverse: @stilkov@innoq.social

Germany
Joined April 2007
Filter
Exclude
Time range
-
Near
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.
4
12
2
103
Many enterprise IT departments have become big fans of an “API-first“ strategy. I think that in general, this is a bad idea. (Thread)
37
251
46
592
Replying to @larsr_h
Zwinkersmiley
3
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.
2
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.
1
1
Maybe we could do a quick online workshop to come up with some rough consensus (or meaningful disagreement)?
1
4
The problem is that it’s a little hard to act upon advice like “use appropriate tools in a pragmatic and reasonable way”, however true that is
1
2
I have an old slide back from the SOA days that advocates for CSDA a.k.a. common sense-driven architecture
2
1
3
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
1
4
(And I can’t rule out I’m missing some of the finer points of DDD terminology)
1
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.
2
2
As a matter of fact, that’s one part I disagree with (at least to a certain degree): martinfowler.com/articles/do…
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
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
From my limited understanding, the core domain (in DDD terms) could be spread across multiple SCSs, but doesn’t have to be
1
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
Thanks, & would love to hear your feedback in more detail, Vaughn
2
7