Clean Architecture Workshop

Thanks to my employer, I could attend a workshop dedicated to the principle of Clean Architecture. This is a typical example of modern domain-centred architectures like

• Hexagonal Architecture
• Onion Architecture

Multitier Architecture

It is important to understand the differences to the historic predecessor, the multitier architecture. I have used this type of architecture in most of my projects. In this approach you would start with your database design, which is already the domain model with entities, relations, constraints. Based on that you would develop the data access layer (DAL), which in turn is consumed by the presentation layer (frontend) or any other service. This is also called database first.

In our team we are also relying very heavily on our database system, which contains dozens of stored procedures to get specific data sets or save data. This has worked quite well, but now our database manufacturer is about to stop providing maintenance updates and we need to switch to another database system. This is one typical scenario when you see how flexible your architecture is. And ours is not, so we will spend months switching everything to the other system.

Clean Architecture

So it was quite interesting to see how domain-centred architectures work and try to achieve more flexibility. In such an architecture, the domain logic sits in the centre, so there are no dependencies to the outer circles or to a specific database. This is the big difference to our current approach with a heavy dependency on the database with its rules and business logic implemented in stored procedures. The domain model contains your entities (like employee, contract, project) which are specific to your business.

The next ring (use cases) knows about the domain and contains use cases like creating a project, updating an employees address, assigning an employee to a project. However, this layer does not know which database or infrastructure is used. Instead it uses interfaces (abstractions) for repositories or an email sender.

In the outer ring, the concrete database classes implement the repository interfaces. This allows – in theory – an easy change of the database. It must be emphasized, that the database in this concept is a rather dumb one without stored procedures or business rules. All of that resides in the inner circles.

One example for this is the preferred workflow with Entity Framework Core, the most commonly used object-relational mapper for Microsoft .NET Core. Instead of creating a database scheme, you define your model in the code and let the framework create the database schema migration for you. Stored procedures are not supported in this flow and are also not intended to be used.

Conclusion

It was useful to get to know this flexible architecture pattern and discuss some of the challenges with it. Software architecture is never black or white but always tradeoffs. This became very clear in the discussions. I am eager to try it out in practice.