[ part 1 | part 2]

In the previous post of the series, I’ve talked about The Use Case Layer of Clean Code Architecture. I’ve shown how we are structuring our business logic code and how it’s helping us keep the code that matters in a place that is decoupled from everything that goes around our applications and micro services. Give it a look, you will better understand how our Use Cases look like.

In this post I will talk about the Entity Layer and how we managed to create a balance between the theory and what is more practical for our everyday coding needs.

Image fromUncle Bob’sClean Code Arquitecture Blog Post — http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.htm

First things first. Uncle Bob’s Clean Code Architecture (CCA) tells us that an Entity is a representation of data of our domain, it’s so dumb that we are only giving the possibility to represent it self in a different way. No database access, nor business logic, only data.

In our apps Models are a key component so, migrating our Models to CCA Entities was, and still is, a really hard process. Also we use ActiveRecord a lot in our Models, which provides us with a straight forward ORM and some other goodies that we can’t just leave behind, at least for now. But we had to make some compromises and Pragmatic Entities are the result of those compromises.

Pragmatic Entities

For us, a Pragmatic Entity is still an ActiveRecord Model that is used to CRUD data from the database and represent it inside our business logic.

As I said before, there are limits to use ActiveRecord Models. The main idea is: There’s no business logic inside a Model. This has implications, mainly for Callbacks and Validations, as I will explain now.