The following points are downsides that we can tame as upsides:
- Suppose you are used to working in silos (such as the DBAs doing the data stuff). In that case, assigning tasks that touch the whole feature may be more challenging, but this can become an advantage since everyone in your team works more closely together, leading to more learning and collaboration and possibly a new cross-functional team—which is excellent. Having a data expert on the team is great; no one is an expert in all areas.
- Refactoring: strong refactoring skills will go a long way. Over time, most systems need some refactoring, which is even more true for Vertical Slice Architecture. That can be caused by changes in the requirements or due to technical debt. No matter the reason, you may end up with a Big Ball of Mud if you don’t. First, writing isolated code and then refactoring to patterns is a crucial part of Vertical Slice Architecture. That’s one of the best ways to keep cohesion high inside a slice and coupling as low as possible between slices. This tip applies to all types of architecture and is made easier with a robust test suite that validates your changes automatically.
A way to start refactoring that business logic would be to push the logic into the domain model, creating a rich domain model. You can also use other design patterns and techniques to fine-tune the code and make it more maintainable, such as creating services or layers. A layer does not have to cross all vertical slices; it can cross only a subset of them.
Compared to other application-level patterns, such as layering, fewer rules lead to more choices (Vertical Slice Architecture). You can use all design patterns, principles, and best practices inside a vertical slice without exporting those choices application-wide.
How do you organize a project into Vertical Slice Architecture? Unfortunately, there is no definitive answer to that, and it depends on the engineers working on the project. We explore one way in the next project, but you can organize your project as you see fit. Then we dig deeper into refactoring and organization.
Project – Vertical Slice Architecture
Context: We are getting tired of layering, and we got asked to rebuild our small demo shop using Vertical Slice Architecture.Here is an updated diagram that shows how we conceptually organized the project:
Figure 17.3: Diagram representing the organization of the demo shop project
Each vertical box is a use case (or slice), while each horizontal box is a crosscutting concern or a shared component. This is a small project, so we share the data access code (DbContext) and the Product model between the three use cases. This sharing is unrelated to Vertical Slice Architecture, but splitting it more in a small project like this is hard and pointless.In this project, I decided to go with web API controllers instead of minimal APIs and an anemic product model instead of a rich one. We could have used minimal APIs, a rich model, or any combination. I chose this so you have a glimpse of using controllers, as this is something you might very well end up using. We go back to minimal APIs in the next chapter.Here are the actors:
- ProductsController is the REST API to manage products.
- StocksController is the REST API to manage the inventory.
- AddStocks, RemoveStocks, and ListAllProducts are the same use cases we have copied in our project since Chapter 14, Layering and Clean Architecture.
- The persistence “layer” consists of an EF Core DbContext that persists the Product model to an in-memory database.
We could add other crosscutting concerns on top of our vertical slices, such as authorization, error management, and logging, to name a few.Next, let’s look at how we organized the project.
Leave a Reply