(most likely) purchase or commissioning • Independent of other systems • UI and persistence • Development and evoluHon • OperaHons • Frameworks and languages • Underlying runHme ‘process’ • Limited interacHon with other systems Independent Limited Independent
are added • Has no concept of the ‘funcHonal separaHon’ of concerns • Only decouples technical concerns • But technical concerns change the least o^en! • How does this architecture evolve as a ‘system’ grows over Hme? UI Logic Data
a monolith if change is slow and terrifying • It’s slow and terrifying because: • Each layer has very low cohesion (covers many concerns) • Each layer depends on the layer below it (albeit abstracted) very signiﬁcantly • The ‘unit of change’ requires too big of a ‘unit of understanding’ (doesn’t ﬁt in your head) UI Logic Data
• Diﬃcult to onboard new developers • Slow and overloaded development environment • Slow applicaHon startup • Diﬃcult to conHnuously test and deploy • Very diﬃcult to scale applicaHon horizontally • Diﬃcult to scale development • Diﬃcult to idenHfy boelenecks and issues • Very diﬃcult to cleanly integrate with other systems
layering is insuﬃcient past a certain scale (mulHple funcHonal concerns in a fast-‐changing environment) • The layers must create boundaries that meet the principles of architecture (modules with high cohesion and low coupling) UI Logic Data
a single responsibility Containerless Organised “verHcally” along business capabiliHes Loose coupling, favouring choreography over orchestraHon Decentralised governance where only the interfaces are agreed Decentralised data management Infrastructure is automated Design for failure 100 to 1000 lines to code EssenHal Why? Why??!???!?