3 ms·
Yeah, that's a recipe for disaster. We've had quite decent success by just splitting along boundaries when something becomes too large or has too many responsib
by dtech 6y ago
Yeah, that's a recipe for disaster. We've had quite decent success by just splitting along boundaries when something becomes too large or has too many responsibilities.
Having too few large services seems much easier to work with an fix than having too many small ones.
- nullsense 6y agoDid you guys split along the equivalent of a bounded context? That would seem to make sense to me in terms of keeping things loosely coupled but still cohesive.
- dtech 6y agoI'd say so. What we did is if you make a description of what a service does like "this service ingests data X and stores it in a database and makes it available as an API and aggregates it into business events and makes predictions based on it" we cut the services on the and's. This example now is 3 services: DB + API, event generator and predictor. I'm still glad we let it evolve that way instead of starting out separately.