Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024 (Category Architecture)
Interesting but strange. report Vertical Slices as an Architectural Concept. The bottom line is that we should design applications with change in mind, because change is the only constant in our industry. Next, the author recalls previous types of architecture
- Three-tier architecture. (n-tier)It was popular during the time of the dinosaurs. In this architecture, we have data access layer, business logic layer, user interface layer.
- Onion architecture, ~~Good thing it's not fake.~~ (onion) In this architecture, the central element is the business rules of the subject area.
- Pure architecture from Uncle Bob. (He loves everything pure: code, architecture, agile.) A mix of best practices from other architectures raised to the level of dogma The author remembers that we do not make code for the sake of beautiful architecture. (Sounds better than pure.)It's about creating features inside the product and making money. So we have limitations, and sometimes it's more important for us to do things than to do things beautifully. So there is tech debt and the need for refactoring. Now the standard approach is to create separate services, but we have problems. High coupling and low cohesion (Of course, the opposite is true.) This makes it difficult to modify and maintain these systems. We often have problems with service methods that have more than one reason to change. (Continuation of single responsibility principle and separation of concern) The very property of systems leads to more connections and more complexity if we don't fight it. The standard multi-tier architecture doesn’t help us – we have problems understanding and modifying the code, as we have to keep all parts of the application in mind. There are also problems with code complexity, performance and scalability of systems.
And the author proposes a silver bullet in the form of a vertical slice architecture, where we have Organization of the code is assumed by use scenarios, not technical responsibility We write separate code for slices, not reuse existing ones. In the slices, we only write the code we need now. If new needs arise in the future, we will add them to the slices. (~~everything 100500What we will do within our architecture~~)
Then there are the advantages of the architecture, which affect the productivity of developers, as it Allows you to quickly create and test functions, which facilitates learning and understanding of the system. Simplifies separation of functions and scaling of individual parts of the application
Here we easily handle the urgency of fitch release Urgent features can be created and tested faster, without compromises in code (simple ~~add water~~ make another slice. ) Custom user code can be written in a separate vertical, which avoids contamination of existing code. Technical debt and refactoring can also be performed more efficiently, as we can give it back in a slice. n
This architecture also helps with the huge services that appear in pure architecture. It can be used instead MediatR, which implements a pattern of intermediary that ensures the interaction of many objects, while forming a weak engagement and eliminating the need for objects to explicitly refer to each other.
And finally, the author says that some code still need to be shuffled. (~~surprise~~) The author proposes a rule of three (||three-fold||)If the code is repeated three times, it should be extracted into a new procedure. But the most important thing the author left to conclude is that domain models are well suited for code sharing, as they model business rules and business changes.
#Architecture #Software #SystemDesign #SoftwareArchitecture