As there are plenty of options for architectural styles, you may have gotten a bit confused in this chapter. You'll have to consider the tradeoffs for each one of them in order to choose wisely. One thing is clear: the Big Ball of Mud approach is not an option, as the code will rot pretty fast. Layered Architecture is a better option, but it presents some disadvantages, like tight coupling between layers. Arguably, the most balanced option would be Hexagonal Architecture, as it can be used as a foundational base architecture, and it promotes a high-level degree of decoupling and symmetry between the inside and outside of the application. This is what we recommend for most scenarios.

We've also seen CQRS and Event Sourcing as relatively flexible architectures that will help you in fighting serious complexity. CQRS and Event Sourcing both have their places, but don't let the coolness factor distract you from the value they provide. As they both come with some overhead, you should have a technical reason for justifying their use. These architectural styles are indeed really useful, and the heuristics to start using them can be discovered in the number of finders on the Repositories for CQRS and the volume of triggered events for Event Sourcing. If the number of finder methods starts growing and Repositories become difficult to maintain, then it's time to consider the use of CQRS, in order to split read and write concerns. And after that, if the volume of events on each Aggregate operation tends to grow and the business is interested in more granular information, then an option to consider is whether a move toward Event Sourcing might pay off.