Clean Architecture & DDD, a mixed approach

At my current work at peya-tech we’ve been using a combined forces architecture for the last 6 months that has worked quite well so far. It consists of a mixture between the concepts of Clean Architecture and Domain Driven Design.

You can find plenty of information of both concepts around, there are great books explaining these topics and other sources. We’ll leave you some sources at the end of this article.

To set us in motion, The Clean Architecture first introduced by Robert C. Martin (aka Uncle Bob) defines an architecture for your software project that separates each layer according to clear different responsibilities. Moreover, Uncle Bob’s concept defines that information flow should follow always the same direction, from the outer to inner layers and back again.

Clean Architecture Diagram

This architecture relies heavily on some widely-known principles, the SOLID Principles, which I recommend you to have a look at.

Our co-star Domain Driven Design, commonly known as DDD, was first introduced by Eric Evans on the book by the same name. What Evans talks about in his book, heavily summarised, is that your software’s model should be really close to your business domain.

Between product and engineering you should talk a ubiquitous language when referring to concepts and that language should be reflected in your code. To build your model he defines some building blocks, such as entities, value objects, aggregates, domain events, services, repositories and factories.

See that blob on the bottom center of the diagram? The layered architecture? DDD says nothing about the architecture of your application. Databases, delivery such as HTTP or gRPC and controllers are not important. Here is where our two concepts combine forces for a brighter future.

Using DDD to model the entities and use cases mentioned in clean architecture diagram has worked out well for us. We can easily understand what our application does, what entities it handles, what it can do is firmly coupled with the user’s use cases. And our outer layers reflect that. We have handlers/controllers that call use cases and map our exposed actions with what we can do. Our entities interact with databases via interfaces in our repositories, it doesn’t matter if it’s a relational, document or graph database.

Here is an example of how we ended up structuring our applications, in this case a Go app.

What we like about this approach is that when you first see the directory structure you somehow get the idea of what the app is about. It handles books, inventory for those, we have customers and subscriptions. If I had to make a guess I’d say we have something like a bookstore application going on.

Is this the only way? Of course not. We are always trying new things, watching out for new ways in which we feel comfortable and proud at the end of the day.

As said, the amount of resources to read and learn from tends to infinity. Keep curious, ask, contribute, debate, agree, disagree. Here’s a list of links that we found interesting and have proven helpful along the way.

Interaction Driven Design, Sandro Mancuso:

Clean Architecture, Robert C. Martin:

Bounded Contexts, Cyrille Martraire:

Thank you for reading!

Software engineer with 5+ years working for startups and some of LATAM’s unicorns. Passionate about high quality, resilient software with focus on product dev.