Many developers think DDD means creating a <code>domain</code> folder, placing domain files inside it, and importing them everywhere.
But honestly, that’s just a trick to avoid import cycles — it’s not real DDD.
Real DDD is a completely different mindset. It’s not about old-school layered or legacy structures. It’s about sub-domain–based dependency injection, where:
<ul>
<li>Each sub-domain handles its own responsibilities.</li>
<li>Sub-domains communicate only through well-defined interfaces.</li>
</ul>
In my approach, there’s no “shared domain” folder.
A domain is not a folder or pattern — it’s about responsibility, independence, and trust.
For example:
<ul>
<li>In a ride-sharing app, the Payment domain should not directly depend on the Ride Management domain’s internal logic.</li>
<li>Instead, Payment defines an interface like <code>RideDetailsProvider</code>.</li>
<li>Ride Management implements that interface to provide necessary ride details.</li>
<li>Payment doesn’t care how Ride Management works internally — it just gets what it needs.</li>
</ul>
This creates a parent–child relationship:
<ul>
<li>Parent domain: The one that requests work (e.g., Payment domain requesting ride details).</li>
<li>Child domain: The one that performs the work by fulfilling the interface (e.g., Ride Management providing the details).</li>
</ul>
You don’t ask someone else to breathe for you, right? Similarly, a domain should work independently within its boundaries, while collaborating through contracts.
I’m still learning DDD, and I believe experience will deepen my understanding — but this is how I see it right now.
<hr>
There’s an important difference between Library Code and Domain Code:
Library code is heavily abstracted for reuse across multiple businesses and supports polymorphism.
Domain code is directly tied to a specific business context (bounded contexts). Excessive abstraction in domain code can be costly and premature.
Domains come from bounded contexts, and communication between domains should be intentional and minimal to avoid over-abstraction.
Even when applying DDD, the code still has layers. Most teams use a blend of architectural styles like Onion, Hexagonal, and DDD together.
Patterns like entities, DTOs, value objects, repositories, and aggregates exist within the domain code because they represent specific business rules and logic.
Library code, which is reusable by multiple businesses, benefits more from abstraction. Domain code should balance abstraction with clarity and direct representation of business needs.
<hr>
💡 Key Takeaway:
DDD is not just a folder structure. It’s about modeling your code around real business responsibilities, creating clear boundaries between sub-domains, and letting them collaborate through explicit contracts — while keeping the right balance between abstraction and practicality.

Jobs is a daily dev squad dedicated to sharing job opportunities, career advice, and community-driven insights for developers across all tech stacks, helping them grow and succeed in the industry.

Jobs

Domain Driven Design is not about creating domain folders but about modeling code around business responsibilities with clear subdomain boundaries. Each subdomain should handle its own responsibilities and communicate through well-defined interfaces, creating parent-child relationships where domains collaborate through contracts rather than direct dependencies. The approach emphasizes balancing abstraction with practicality, distinguishing between library code (heavily abstracted for reuse) and domain code (tied to specific business contexts).

Domain Driven Design: Key Concepts and Practical Approach

DDD is like practicing scales in music. You don’t want to encode your entire model around DDD to avoid rigidity. However, your modeling skills and output improve the more you practice the fundamental concepts.

Really DDD is very interesting for Maintainability.