Clean architecture for our back-end

Today I want to continue discussing the architecture we came up with for our back-end service. In the previous article I brought up some arguments why it was important for us to separate read and write models. And the main thing that made it clear was that we operated with two different data sets for read and write operations. But I didn’t go much in to the details on how we arrived at such a different models. And this aspect of CQRS will be the topic of today’s article. Before we even realized we need to apply CQRS pattern in our design we decided to follow Uncle Bob’s Clean Architecture the same architecture we used in our mobile application development.

And the the reasoning that brought us to this architecture I lied down in one of my previous articles. Although on both platforms the overall architecture was the same but implementation details were quite different. The main attraction point of this architecture was possibility to build the server side application around the Domain Model and apply Domain Driven Development. There are several definitions for Domain Model and some of them you can find here but for us in the design process more important was to understand the peaces that constitute the Domain model. It allowed us in the next designing steps to decide whether we need a separate Domain model layer or entities were just enough. Quite often I notice that the architecture does not make a big difference between the bare bones domain entities and full domain model. In first case entities are just a database relational model, and they serve as in memory tables. In many cases especially in ASP.NET world (the framework we are using to build our back-end services) Object Relational Mappers like Entity Framework require to separate entities from the CRUD operations and thus giving impression that full-fledged Domain model is created, but in fact you end up with something what is called Anemic Domain model which is considered an anti-pattern. So following the advise of Eric J. Evans in his book Domain-Driven Design: Tackling Complexity in the Hart of Software we noted for ourselves following parts that should be presented in our Domain Model in order to consider it us a separate layer:

  • Entities accompanied with business methods
  • Value objects
  • Repositories
  • Aggregates
  • Bounded Context

By analyzing our model designed for Android or iOS platform and for our back-end platform we realized that only our back-end model meets Domain Model criteria and deserves a separate layer but in case of mobile phone platforms we ended up with simple entities that were the part of application or Use Cases layer.

By modeling entities we replicate real life entity attributes, like person’s name, surname or gender that are operated by methods encapsulated in the same entity or in service. At the end of the modeling process we come up with our business model that further can be converted to the Entity-Relationship model, that is used to build the database. In such way Domain model or plain entities are tightly bound to normalized ER model. And one can live only with one ER model until the moment when displayed information starts more and more deviate from the ER model and in order to fetch the data from database more complex queries are required. And this is the time when we started to consider CQRS. But now it was not clear how to integrate the CQRS in Clean Architecture layers and we turn to the mighty Google for someone’s else experience and we found this wonderful talk that showed us exactly what we were looking for and so we ended up by extending the application layer with commands and queries and adding separate Database context or our queries.

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

Leave a Reply