We've all worked with a monolith and we all know the unbearable pains associated with them. Controllers fatter than Thomas the Tank Engine's Fat Controller, repositories that quickly become a dumping ground for data access with zero cohesion and arbitrary services that make the SOLID principles cry. All of these violations make for a codebase that's hard to maintain, tough to evolve and a terror to work with.

In this talk we'll look at an alternative architectural approach utilising the Command/Query Responsibility Segregation pattern to better isolate and decouple our business logic from our framework whilst separating our read models from our write models. Whilst on our CQRS journey we'll stop and take a look at libraries such as MediatR and Brighter that enable such an architectural pattern. We'll also look at how this separation can lead to organising our API into feature folders for a better project structure and the additional benefits that come with such a concept.

We'll also look at how we can utilise pipelining features in MediatR and Brighter to introduce cross-cutting concerns such as monitoring, metrics gathering, logging and caching to our API.