Domain Driven Design for monoliths

Reach a manageable state for your app in 5 domain-driven steps

Let’s face it, using a framework to start a project is the easy way to-go, we can query the database directly, we can call functions from any part of the code, we don’t have to think too much about the organization because we are already plugged in into an “architecture”. However, the time progresses your codebase grows exponentially with your business needs and it becomes in something difficult to maintain. The convention-over-configuration design principles that some frameworks use, at some point, will hurt your feelings when you look at your code converted into a Big Ball of Mud.

Alert symptoms

1. Refactoring is difficult and tedious, methods and classes depend on other classes.
2. Changing code in one area produces side effects in other areas of the code.
3. Your business objects are growing up fast and is difficult to keep them in your head.

DDD to the Rescue

The Domain Driven Design approach aims to help with complex business logic, the key principle in DDD is that the software you build must closely mirror of business. We need then, do the homework and understand how our business domain works.

From Legacy to DDD

1 — Draw a context map

A diagram that mixes business objectives and implementations of software systems. It’s useful for visualizing dependencies between components.

2 — Understand your Domain

A Domain is what the business does, and the context of how it does it.

Review your context map!. If multiple business domains are converging into your code it’s time for letting the “microservices” act.

3 — Define the bounded contexts

Define Bounded Contexts that fulfills the goals of the business in the real world.

4— Embrace the code

Group your code to visualize your app in it’s constituent components.

5 — Escape from frameworks

Let the framework deal only with the HTTP requests.

Good luck. You can do this.