DDD and Clean Architecture

Last week I made a presentation to my current team about Domain Driven Design and Clean Architecture. Currently we have many applications and legacy systems that are hard to maintain and understand. There was an intent of using Hexagonal Architecture before but it was not well implemented. Next is an extract of this presentation.

Why Domain Driven Design?

DDD helps teams build better software by closing the gap between buissness reality and code by focusing on the domain and improving the communication between the business and the software.

  • We are a big company with many teams working on the same domain
  • There are many terms and concepts that are not well defined or defined at all
  • We are having communication issues between teams and even inside the teams
  • Lack of documentation and understanding of the systems, even in the new ones
  • Increasingly large and complex codebase

We want to address these issues and improve the full development cycle, from the business requirements to the code.

What does DDD means for the code ?

  • Use of a common language shared by developers and domain experts.
  • Clear Boundaries: DDD emphasizes dividing your software into bounded contexts
  • Modularization: Manageable modules based on domain concepts
  • Clear business rules (uses cases): ensure consistency within a specific domain.
  • Entities and Value Objects (Domain)
  • Favors declarative code and less imperative implementation details

Combining DDD with Clean Architecture

Why do we need application architecture for ?

All software architectures have the same objective, which is the separation of concerns.

We want our applications to be:

  • Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
  • Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
  • Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
  • Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
  • Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

What is Clean architecture ?

The Clean Architecture is the system architecture guideline proposed by Robert C. Martin (Uncle Bob) derived from many architectural guidelines like Hexagonal Architecture, Onion Architecture, etc… over several years. This is one of the guidelines adhered to by software engineers to build scalable, testable, and maintainable software.

The Clean Code Blog

What I like most about this architecture is that it is not a novel architecture but a combination of existing architectures including Hexagonal Architecture, and is very simple to grasp, we only need to follow one rule to implement it: The Dependency Rule.

The Dependency Rule

The overriding rule that makes this architecture work is The Dependency Rule.

  • Source code dependencies can only point inwards.
    Example: An application service or use case will never import an Infrastructure Repository. A domain entity will never import a use case.
  • Nothing in an inner circle can know anything at all about something in an outer circle.
    Example: The application use case (same for the domain) does not need to know what database or framework we are using.
  • Data formats used in an outer circle should not be used by an inner circle, especially if those formats are generated by a framework in an outer circle. We don’t want anything in an outer circle to impact the inner circles.
    Example: If we change hapi for express or mssql for sql, our business logic and domain should continue to work as long as the model remains.

You can read the all about Clean Architecture in The Clean Code Blog.

Combining DDD and Clean Architecture, a proposal

As you see in left side of the image we have a weird folder structure in this particular project, and the worse is that code runs jumping from one side to the other (for example: service -> helpers -> lib -> database) with no clear boundaries and no bussiness rules. It's a mess.

What we are proposing

In the right side of the image we have a proposal for a new folder structure and a new way to organize the code under the DDD and Clean Architecture principles. This will help us enforce the separation of concerns and the dependency rule (white arrow).

Next steps are:

  • We will work on what is the domain with product owners and domain experts
  • We will have some sessions to discuss this proposal with real code examples and different approaches to implement it
  • Talk about where to start and how to migrate the current codebases iteratively

Is important to mention that this is not a silver bullet, but a proposal to improve the current state of our systems and there could be some projects that are not a good fit for this architecture or the migration doesn't worth the effort.

I will write more about this in the future, for now I hope this inspires you to start the conversation in your own team if you are having similar issues.

RSS Atom