.@adamralph giving a practical guide on finding service boundaries. Hoping this ties up earlier sessions on DDD, architecture and technical debt. #ndcoslo
Systems tend towards the Big Ball Of Mud architecture due to entropy.
This is often the gradual accretion of small, innocuous changes over a long period of time.
A single entity shared between different services that contains all the information that every service requires will result in close coupling.
Prefer thin, loosely coupled events and entities.
Services are aligned to business processes and entities, not to a layer within the system.
Systems are aligned to technical boundaries. Services are aligned to business boundaries.
Anti-requirements can be more valuable than stated requirements. The customer may not know exactly what they want, but they will probably know what they *don't* want.
Modelling is not about tangible things.
Group properties by use cases. Try not to name the containing entity early in the modelling process, as people get attached to the name of the box that something is put in.
Entity-first thinking leads us to inefficient models.
Chattiness between services indicates tight coupling.
High-level groupings are revealed from the details. Not the other way round.
Microservices themselves do not prevent entropy and the return to a big ball of mud. Except this time we have the overheads of containers and HTTP calls.
Let go of physical boundaries around deployable units - prefer boundaries around business use cases.
SOA is not a silver bullet. Like any concept, there is a time and a place for it.
