Domain-driven design consulting is how a complex product stops being a pile of screens and starts being a model of the business: the words people actually use, the rules that must never break, and the boundaries between teams that only look like they share a concept. When “order”, “customer” or “account” means three different things in three parts of the company, the code inherits the confusion, and every new feature gets more expensive.
Contents
At CodeWiz we facilitate the modeling and then implement it. We run workshops with the people who know the business, draw bounded contexts, design aggregates that protect invariants, and write the model into Laravel, Node.js or an existing codebase. The diagrams are a means to an end. The deliverable is code your team can change without being afraid of it, plus a shared language that product and engineering both recognise.
This service is for products whose rules no longer fit in controllers and database columns: marketplaces, billing, logistics, bookings, multi-tenant SaaS, and any system where a wrong state transition costs real money. If the application is a straightforward CRUD tool with little policy behind it, we will say so and keep the design simple.
For driven design, open-source tools are the default when they fit the job.
Domain Modeling: The Core of Domain-Driven Design Consulting
Domain modeling is a structured conversation that turns how the business works into a model precise enough to code. We use event storming for the big picture and example mapping when a single rule needs to be pinned down. Sticky notes are the tool; the point is the arguments they surface before those arguments become production bugs.
What a modeling session produces
- A timeline of domain events: the facts that matter, written in past tense (“OrderPlaced”, “InvoiceOverdue”, “SeatReleased”), not screen names.
- Commands that cause those events, the actors who issue them, and the policies that react (“when payment fails, release the seat”).
- Hotspots: rules nobody can state cleanly, words that split the room, and external systems the process depends on.
- Concrete examples, including the unhappy ones: partial refunds, double submits, a booking that spans midnight, a tenant that closes mid-invoice.
A ubiquitous language, written down
The ubiquitous language is the small vocabulary of the domain, used in conversation, in the user interface and in class names. We keep a short glossary in the repository. If the business says “reservation” and the code says “temp_order_row”, one of them has to change. Renaming is part of the work, not a cosmetic follow-up. Alberto Brandolini’s event storming site is the reference we point teams to before a workshop, so the format is familiar and the session is spent on the domain rather than on the method.
Bounded Contexts: One Word, One Meaning
A bounded context is a boundary inside which a model is consistent. “Customer” in sales (a lead with a pipeline stage) is not “customer” in billing (a legal entity with a tax ID) and not “customer” in support (a person writing a ticket). Forcing one table and one class to serve all three produces nullable columns, special cases and bugs that only appear at the edges.
We draw contexts from the language and from the teams, not from a hoped-for microservice diagram. A context can be a module in a single Laravel or Node.js application, a schema in PostgreSQL, or a separate service. The boundary is what matters. Splitting deployables comes later, only when a team or a scaling need actually requires it. Martin Fowler’s explanation of domain-driven design is a good short briefing for stakeholders who will be in the room.
How we decide a boundary is real
- The same noun has different rules, different lifecycles or a different owner on each side.
- A change on one side should not force a release on the other.
- Each context can be explained to a new developer in one sitting, without a tour of the whole company.
- Integration between contexts is explicit: an API, a domain event or a translated ID, never a shared mutable table.
Aggregate Design That Protects Business Invariants
An aggregate is a cluster of objects treated as one unit for change. It has a root (the Order, the Subscription, the Booking) and it is the only door through which those objects are modified. The reason to bother is an invariant: a rule that must hold every time the aggregate is saved. An order cannot be placed with no lines. A seat cannot be sold twice. A refund cannot exceed what was captured. Those rules live in the aggregate, not in three controllers that all forget a case.
The rules we design by
- Keep aggregates small. A “Customer” that contains every order, invoice and ticket will lock too much and load too much.
- Reference other aggregates by identity, not by object pointer. The order stores a
customerId, and it asks a domain service when it needs a fact from outside. - One transaction per aggregate. Cross-aggregate processes (place order, then charge, then notify) become policies and domain events, not one giant database transaction.
- Value objects carry the awkward rules:
Money,DateRange,Email,Quantity. A money amount with a currency cannot be a naked float.
A condensed PHP aggregate, the shape we use in Laravel applications, shows the idea. The constructor is private, so the only way to get an order is a named factory, and place refuses an empty order:
final class Order
{
private function __construct(
private OrderId $id,
private OrderStatus $status,
private array $lines,
) {}
public function addLine(Sku $sku, Quantity $qty, Money $price): void
{
if ($this->status !== OrderStatus::Draft) {
throw new OrderClosed();
}
$this->lines[] = new OrderLine($sku, $qty, $price);
}
public function place(): OrderPlaced
{
if ($this->lines === []) {
throw new EmptyOrder();
}
$this->status = OrderStatus::Placed;
return new OrderPlaced($this->id);
}
}The same shape translates directly to TypeScript or to a framework-free core that a Laravel or Express adapter calls. Persistence stays outside: a repository loads and saves the aggregate, and tests exercise place with no database. The same discipline is what keeps an online store from losing an order or a payment in the gap between two steps, which we have written about in keeping every customer action and order recoverable.
Strategic Design and Context Maps
Strategic design is the map of how contexts relate, and of which team owns which model. A context map stops two teams from “just sharing the users table” and makes the cost of each relationship visible. We pick the relationship on purpose. Most pain we inherit comes from an accidental shared database that nobody agreed to maintain.
| Relationship | What it means | Use it when |
|---|---|---|
| Partnership | Two teams evolve a shared area and succeed or fail together | The overlap is real and both sides can plan jointly |
| Shared kernel | A small piece of model both teams change, guarded by joint tests | The shared part is tiny and stable enough to be worth the coupling |
| Customer–supplier | Upstream accepts downstream needs as input to its planning | One context genuinely serves another team’s product |
| Conformist | Downstream adopts the upstream model as it stands | You do not control the other side: a payment provider, a legacy system |
| Anti-corruption layer | A translation layer keeps a foreign model out of yours | Integrating legacy software or a third-party API whose language is not yours |
| Open host service | Upstream publishes one stable protocol for many consumers | A platform API that several contexts already depend on |
| Separate ways | No integration. Duplication is cheaper than a shared model | The words overlap, but the problems are actually different |
Modules first, services when they earn it
A bounded context does not have to be a network service. Inside a modular monolith, each context is a namespace with its own application service, its own persistence and a public interface other modules are allowed to call. We extract a service when a team needs to deploy independently, when the load profile is different, or when a context is ready to be replaced. Doing it earlier creates distributed transactions and operational work without a payoff. When a context does outgrow one database, the seam is already there – the same kind of boundary discussed in our guide to sharding and partitioning.
Tactical Building Blocks We Implement
Strategic design decides where the lines are. Tactical design is the code inside one context. We use the classic building blocks only where they earn their keep:
- Entities have identity and a lifecycle. Two orders with the same contents are still different orders.
- Value objects are defined by their values, are immutable, and hold rules that would otherwise leak into every query.
- Domain events record something that happened, named in the ubiquitous language, and are the input to other contexts and to projections.
- Domain services hold an operation that does not naturally sit on one entity, such as a pricing policy that needs a catalogue and a contract.
- Repositories load and save aggregates. They are not a generic dump of every query the user interface needs.
- Factories create a valid aggregate. Half-built objects never sit in the database waiting for a later request to finish them.
We deliberately skip the ceremony that does not help a given codebase: no repository interface per table “because the book says so”, and no domain event bus for a rule that a single method can enforce. The test of a pattern is whether a new developer can find the business rule in one place.
When Domain-Driven Design Is Worth It
DDD pays for itself when the complexity is in the business, not in the framework. Signs that the investment is justified:
- Rules are explained differently by different people, and production bugs cluster on state transitions.
- New features require reading five services to know whether a change is safe.
- The database schema is the only documentation, and it contradicts the way sales describes the product.
- Several teams commit to the same modules and block each other.
A marketing site, a simple internal CRUD tool or a thin wrapper over one external API does not need aggregates and context maps. We start from the business problem, the same way a product engagement should, and we have described that stance in how a software partnership follows the business. If a cleaner module structure is enough, that is the recommendation.
Common Modeling Mistakes We Fix
- One giant aggregate (“the Account”) that every feature locks and loads.
- An anemic model: data classes with no behaviour, and rules scattered through controllers that drift apart.
- Bounded contexts drawn as one service per database table.
- A ubiquitous language that exists in a slide and nowhere in the code.
- Sharing tables across contexts, so a column rename becomes a cross-team incident.
- Modeling the current database instead of the business, which freezes today’s accidents into the new design.
What Drives the Cost of Domain-Driven Design Consulting
We estimate after a short look at the product and the code, not from a generic package. The effort follows a few predictable factors:
- How many distinct languages the organisation actually speaks, and whether the people who know them can attend workshops.
- The number of contexts in scope. Modeling one messy ordering flow is a different project from mapping an entire company.
- The state of the code: a modular Laravel or Node.js app absorbs a model faster than a single 8,000-line controller.
- How much behaviour must move, and whether data has to be migrated to match the new boundaries.
- Whether we stop at a context map and a pilot aggregate, or implement the model across the product.
How We Work
- Discovery: we read the product, the code and the bug history, and talk to the people who operate the rules day to day.
- Modeling: event storming and example mapping, a glossary, and a first cut of contexts and aggregates.
- Agreement: a context map, the invariants each aggregate owns, and a scope for what will change in code now.
- Implementation: the model lands in the codebase with tests that state the rules in domain language, and adapters for HTTP, queues and the database.
- Walkthrough: we replay real scenarios, including failures, with the business and adjust the language where the model still feels foreign.
- Support: as new rules appear, we extend the glossary and the aggregates instead of adding another special case in a controller.
Why CodeWiz
- We implement, not only facilitate: workshops end in Laravel, Node.js and database changes, not in a folder of diagrams nobody opens again.
- Technology serves the business: we will not introduce aggregates, events or extra services where a simple model is the honest fit.
- Open-source first: the model lives in your repository, with ordinary PHP, TypeScript and PostgreSQL, and no proprietary modeling suite.
- Full-stack context: APIs, data, queues and the user interface are designed around the same language, because we build all of them.
- Fair pricing: premium development without premium prices, from our team in Banja Luka, working remotely with clients locally and internationally. More about CodeWiz.
Frequently Asked Questions
How much does domain-driven design consulting cost?
A focused workshop and a written model for one area of the product is a short engagement. Implementing aggregates, moving behaviour out of controllers and migrating data across several contexts is a larger one. We quote after discovery, once we know how many languages and code paths are in scope.
Do we need domain-driven design for a CRUD application?
Usually no. If the screens map cleanly to tables and the rules fit in a handful of validations, a well-structured modular codebase is the better investment. DDD earns its place when state transitions and policies are where the bugs and the delays live.
Does domain-driven design mean microservices?
No. Bounded contexts are logical boundaries. They map cleanly onto modules in one application, which is where we usually start. Separate services are a later decision about deployment, team ownership and load, not a requirement of the method.
How long does a modeling workshop take?
A single important flow is often clear in one or two sessions. Mapping a whole product, resolving conflicting vocabulary and checking the model against the existing schema takes longer, and the implementation that follows is where most of the calendar time goes.
Can you apply this to an existing Laravel or Node.js codebase?
Yes. Most of the work we do is on systems that are already live. We introduce the model one context at a time, behind the current API, and move rules across when tests prove the behaviour matches. Users do not get a rewrite; they get fewer broken edge cases.
Ready to Put the Business Rules in One Place?
Tell us where the language breaks down and which rules your team no longer trusts the code to enforce. We will propose a modeling scope that fits the product you have. Contact us to talk it through, or see our domain-driven design services.