The code does not reflect the business
Folders are organized by technical layers, but rules, responsibilities, and business use cases are scattered.
DDD & Hexagonal Architecture
Domain boundaries that make code clearer, not more ceremonial.
LRJI helps teams use DDD and Hexagonal Architecture to clarify responsibilities, isolate the domain, reduce coupling, and make architecture decisions visible in the code.
The goal is not to impose vocabulary. The work is to find the right boundaries, ports/adapters, and level of discipline for TypeScript, Node.js, NestJS, or full-stack teams that still need to ship.
Signals
When DDD and Hexagonal Architecture become useful
These approaches are relevant when they fix a real understanding, coupling, or delivery problem. Otherwise, they mostly add vocabulary.
Boundaries change depending on who explains them
Product, engineering, data, support, and integrations do not describe the same domains or responsibilities.
Adapters dictate the domain
ORM, framework, broker, external API, or identity provider shape the business rules directly.
Tests are hard to write without infrastructure
If testing a business rule requires database, broker, HTTP, or the full framework, the domain boundary is probably too weak.
DDD vocabulary exists, but the effects do not
The team talks about entities, services, repositories, or ports, but maintainability and speed of change do not improve.
Scope
What gets clarified
The work starts from the real system. We keep what helps delivery and remove abstractions that do not pay for themselves.
- Bounded contexts and language
- Identify useful domains, responsibilities, ambiguous concepts, and translation points between teams or systems.
- Use cases and domain
- Express business rules and application workflows without depending directly on framework, database, or transport.
- Ports, adapters, and integrations
- Define contracts between domain, infrastructure, APIs, messages, external providers, and storage.
- Progressive migration
- Introduce structure into an active codebase through modules, tests, refactorings, and the first high-impact boundaries.
Position
The LRJI position
DDD is useful when it improves decisions and code. Hexagonal Architecture is useful when it protects the domain without freezing the team.
Start from real tension
We do not slice to satisfy a diagram. We slice where coupling, ambiguity, or frequent change costs too much.
Do not worship patterns
Entity, aggregate, repository, port, or adapter must solve a precise problem. Otherwise, remove it.
Make tests simpler
A good boundary lets the team test faster, more locally, and with less mandatory infrastructure.
Protect delivery
Introduction must happen through usable increments, not a massive reorganization that blocks the roadmap.
Format
How the engagement works
The format can be diagnosis, framing, or hands-on support. The thread stays the same: clarify, prove in code, then transfer.
- 01
Read the business flows
Use cases, events, rules, data, integrations, and team responsibilities are mapped together.
- 02
Choose the first boundaries
High-impact areas are prioritized: places that change often, break often, or block understanding.
- 03
Prototype the structure
A module, use case, port, or adapter becomes a concrete reference instead of a theoretical document.
- 04
Install team rules
Conventions, tests, examples, ADRs, or reviews guide the team so it can continue without depending on the consultant.
Outputs
What the team gets
The outputs should be visible in the codebase and in team decisions.
- Clarified bounded contexts, responsibilities, and business vocabulary.
- Target application structure: use cases, domain, ports, adapters, and modules.
- Code examples or first pull requests showing the expected structure.
- Progressive introduction plan for an active or legacy codebase.
- Tests and contracts proving the boundaries improve maintainability.
- ADRs, conventions, or review rules that keep the structure alive.
Proof
Relevant experience
DDD and Hexagonal Architecture were useful when they clarified real platforms, not when they added jargon.
Hexa
Banking: critical authentication platform
Hexagonal Architecture around Keycloak, provider abstraction, and more testable application boundaries.
0 -> prod
SaaS: tactical DDD from the foundations
TypeScript and tRPC foundation with explicit domains, full-stack contracts, and shift-left practices.
7 -> 1
Retail: simplification through clearer boundaries
Migration toward a more maintainable primary deployable, with reduced coordination and clearer delivery coherence.
Possible next steps
Depending on the real need
DDD and Hexagonal Architecture can be the central topic or one part of architecture, migration, or event-driven work.
When the decision is broader
Frame the overall software architecture before fixing domain boundaries.
See software architecture consultingWhen legacy blocks delivery
Introduce boundaries progressively during legacy migration instead of reorganizing the whole codebase.
Legacy MigrationWhen asynchronous flows dominate
Connect domain events, integration events, contracts, and ownership to the real domain model.
See event-driven architectureWhen diagnosis is missing
Audit existing boundaries before introducing new patterns.
Start with an architecture auditFAQ
FAQ
Is this only for greenfield projects?
No. It is often more useful on existing products, as long as it is introduced progressively and targets areas where weak boundaries are actually expensive.
Do teams need to adopt every DDD concept strictly?
No. Vocabulary only matters when it improves communication and code. LRJI favors concepts that produce measurable impact on maintainability and delivery.
Does this work with NestJS or other frameworks?
Yes. The framework can stay the driving adapter. The key is not letting the framework become the domain model.
Next step
Bring an area of the system where boundaries are expensive.
LRJI helps turn that area into a clearer model, steadier application structure, and an introduction path the team can actually follow.