Why This Topic Matters
Over the past couple of years, I've observed a surge in conversations about applying Domain-Driven Design within Angular projects. What strikes me is that much of this discourse revolves around concerns that are either tangential to DDD or have drifted quite far from its foundational principles.
Attendees of my Angular and Architecture trainings, participants in my NG-Poland workshops, and countless individuals I encounter in the community—mostly frontend developers, particularly from the Angular ecosystem—tend to frame DDD discussions around specific tools and particular project layouts.
Furthermore, I frequently come across social media posts like this one:
To be clear, asking questions is perfectly legitimate (I'd rather have questions that can't be answered than answers that can't be questioned). Still, all of this points to a broader confusion within the Frontend/Angular community about why, when, and how one would actually approach Domain-Driven Design.
Ultimately, there's an expanding semantic diffusion occurring in frontend circles around DDD, and it's doing more damage than good (in essence, semantic diffusion takes place when a term is used without genuine comprehension, and over time, its meaning becomes corrupted).
That's precisely what I intend to tackle in this article.
To make DDD concepts more tangible, let's imagine we're developing a system where patients can book appointments with doctors and specialists to address medical concerns. In simple terms, we're constructing a medical appointment platform.
We'll consistently draw examples from this domain.
DDD is a methodology where grasping the primary concepts and building blocks is relatively straightforward (see: DDD at a glance below). However, it demands years of dedicated effort to accumulate the practical experience—not merely theoretical understanding—required to apply it effectively for the advantage of your product.
Getting abstract concepts right and subsequently reifying them within your business is challenging.
A primary issue with DDD is that many adhere to a superficial understanding yet label their actions as "practicing DDD". Frequently, this amounts to taking existing code or organizational structures and merely attaching DDD terminology to them.
Fortunately, not everyone falls into this pattern. Consequently, DDD has empowered substantial and intricate businesses to "manage their complexity" and scale effectively, even enabling expansion in various directions.
Conversely, for other organizations, DDD turned out to be an unfulfilled promise, resulting in squandered effort, time, and resources. This has fostered a lasting skepticism toward anything DDD-related.
(this is where my frustration lies).
DDD is a tool. In capable hands, it proves invaluable. In the wrong hands, the opposite holds true.
There's a considerable number of frontend developers who equate organizing code into modules and automating monorepo tooling with "implementing DDD in Angular". (we'll revisit monorepos shortly 😁)
That perspective couldn't be more incorrect.
DDD is an approach that you execute within your product, business segment, and across the entire organization.
But not in isolation on the Frontend.
To simplify, you could say that business semantics should define technical boundaries. However, these technical boundaries encompass the entire stack: Frontend, Backend, Database(s)—as well as activities like Deployment, Monitoring/Observability (DevOps), and so forth.
🔥 You cannot practice DDD on the Frontend in isolation, because your frontend is not a standalone product. 🔥
The frontend isn't an independent "module" either. If that sounds controversial, I'd recommend exploring Simon Brown's C4 model for architecture documentation. It's an extensive subject with various interpretations, but what matters for our discussion is:
- C3 - Components - this layer represents logical architecture, defining logical dependencies between modules, such as when processing a customer charge requires card information from another system component
- C2 - Containers - this layer represents deployment architecture, identifying deployable artifacts (binaries, bundles, etc.)
Certainly, you'll typically deploy the frontend separately from the backend (C2). But more often than not, a business module (Bounded Context, elaborated on later) incorporates Frontend, Backend, and Database(s) as a cohesive unit (C3).
Thus, you shouldn't sever frontend capabilities from their backend counterparts. They collectively achieve a business objective. When you design a model—data structures along with their semantics—certain parts of it (specific interfaces) are shared between server and client; this constitutes a contract (DTOs, Data Transfer Objects), frequently automated via Swagger/OpenAPI or Pact.
Is Frontend-Specific DDD Impossible Then?
Don't misunderstand me 😉 you can absolutely apply DDD to your frontend. But... that presupposes product-wide deliberations about modularity (Bounded Contexts), as well as dependencies between these Contexts (illustrated in Context Maps, covered later).
Allow me to reiterate: DDD is a methodology centered on OUR PRODUCT and COMPREHENDING THE BUSINESS. That's where our efforts commence. That's also where we verify that our actions are genuinely meaningful. Above all, it's the business—not the technology—that drives our iterative improvements.
If you approach DDD from a purely technical standpoint, YOU'RE FUNDAMENTALLY MISTAKEN. Severely mistaken.
What does this mean in practice? First and foremost, if your focus is primarily on your preferred framework, programming language, or technology stack, DDD has no place for you.
In DDD, your paramount concern is THE PRODUCT. This entails actively seeking to understand:
- How does your product generate revenue? What elements could enhance or diminish that revenue?
- In our medical scenario: do we charge each patient individually, or do we offer corporate healthcare packages where we bill a company for multiple employees?
- What service does the customer actually purchase?
- Are patients charged per appointment, or is there a subscription model or another arrangement?
- What value is delivered to your customer? How do they derive benefit from it?
- Is it a straightforward one-off procedure like tooth extraction, or a prolonged process involving numerous appointments, such as cancer treatment?
- What is your billing mechanism for customers?
- Per appointment, via subscription, or on a recurring schedule?
- How does the customer engage with your product? What enhances their experience, or what obstacles could be eliminated? Do you interact with customers directly, or do you merely receive Jira tickets?
- How CRUD-like is your interface—or how effectively does the UI convey the business process to the user (CRUD-based vs. task-based UIs)?
- How does your company gain market advantage relative to competitors? In other words, which system components should you enhance to create a competitive edge: a CRUD module for internal staff, or an experimental customer-facing interface?
- A web interface for a medical app is unremarkable. The same applies to a mobile app. What compelling business feature would prompt someone to switch from one medical provider to another?
- Here, you're looking for the "Genesis" section of Wardley Maps.
- What are your business KPIs? Do you monitor them? Do you even consider them important?
- An illustrative KPI for a stream-aligned team might be boosting utilization of less popular doctors' availability to optimize their services.
- Another KPI could involve minimizing last-minute appointment cancellations, which are costly to the business.
- Are there scarce resources within your business that different customers contend for? In essence, if customer A reserves a resource, is customer B precluded from obtaining it? Is there a finite quantity of these items or services constrained by time, period, amount, or otherwise?
- In a medical center system, the scarce resource is doctor and clinic availability. Once a specific time/location slot is booked, no one else can use it: First come, first served.
And the list continues extensively.
At this juncture, you might be questioning why I'm not extensively discussing subdomains and bounded contexts along with other popular DDD terminology.
The reality is that these are merely formalities. They aren't the core of what DDD seeks to solve. They're specialized vocabulary that facilitates quicker communication, providing a mental model / framework upon which we can construct our understanding.
Allow me to outline DDD's fundamental concepts in straightforward terms...
Strategic vs. Tactical Approaches
First, we have Strategic DDD and Tactical DDD.
Strategic DDD addresses business mechanics, capabilities, opportunities, and challenges. Meanwhile, Tactical DDD focuses on technological execution—essentially, how to implement these concepts and ensure they function correctly in terms of both scale and business complexity.
Strategic DDD further divides into the Problem Space and the Solution Space.
Understanding Domains and Subdomains
We haven't yet addressed the first "D" in DDD. A "domain" refers to the area in which a business operates. For an online retailer, that might be e-commerce. For a package delivery company, it would be logistics or freight. In our medical app scenario, it could be healthcare.
Does "healthcare" feel somewhat expansive, encompassing numerous diverse concerns? You're absolutely right! To arrange a patient's appointment with a specialist, we need to consider:
- Which doctors are accessible to us?
- At which clinic or alternative location will the appointment occur?
- At what precise date and time? Specifically, when are both the doctor and clinic free, and does the patient align with that availability?
- How will the patient settle payment for the service?
- Are there referral initiatives that enable patients to bring in other patients to our facility?
- Do we maintain records of patient appointment history? If so, how do we utilize that data? What advantages can we derive from it?
- What is our communication strategy with patients?
- How do we handle unforeseen circumstances, such as doctor unavailability? Scheduled appointments might require cancellation or rescheduling.
That's a substantial set of challenges our business must resolve and manage. These could be digitized within an IT system, but they might also be handled manually by staff (refer to: sociotechnical systems).
Each of these questions can be viewed as a component of the broader domain, hence the term "subdomains".
Domains and subdomains are elements of the "Problem Space". They aren't subject to our design choices; rather, they reflect how our business operates in reality.
Our task is to uncover them.
Defining Context Boundaries
Yet we have agency in deciding how to approach these challenges. The "Divide and Conquer" strategy lets us break down a large, unwieldy problem into more manageable pieces. We partition the whole system into smaller, more independent modules, which we call "Bounded Contexts".
At this stage, we deliberately set technology aside. Whether the final deployment is a frontend monolith, a set of MicroFrontends, a monorepo, or multiple repositories is not the primary concern. Well-defined Bounded Contexts are flexible enough to work within any architectural setup.
The choice of how to partition the system, and how many contexts to create, rests with us. In theory, the number of viable configurations is limitless.
Nailing down Bounded Contexts is the very core of DDD practice. A frequent reason DDD initiatives fail is that teams rush straight into the tactical phase (implementation) without giving proper thought to the strategic phase.
So, what's the right way to discover these contexts?
This is where "Domain Experts" become essential. If you're building a "product" (rather than just picking up tickets), your company likely has individuals who truly grasp how the business operates. These could be analysts, product owners, specialists, or even executives. Their formal job titles are irrelevant; what matters is their deep understanding of the business itself.
Mapping Context Relationships
Bounded Contexts strive for autonomy, yet some degree of inter-context communication is often unavoidable. The goal is to keep this communication to the absolute minimum necessary.
From an architectural viewpoint, it's crucial to bring some order to these dependencies. This is where Context Maps prove useful, along with their associated patterns, including: Anti-Corruption Layer, Open Host Service, Shared Kernel, and others.
The following is a sample, simplified Context Map. It illustrates the boundaries that might exist between different contexts:
Keep in mind that this is by NO MEANS A UNIVERSAL map for all medical software. I've made numerous assumptions about how the underlying business works. Different companies will likely arrive at completely different maps, shaped by their unique systems, processes, and business rules.
Also observe that there isn't a strict 1:1 relationship between Subdomains and Bounded Contexts. Or at least, there doesn't have to be. Once again, this is a nuanced topic for a future discussion.
What really matters right now is the following point:
The Frontend Is Not Its Own Bounded Context
The frontend is simply a layer that slots into the Context Map. So it's more accurate to practice Angular inside a DDD-oriented product than to try to do DDD solely within an Angular application.
A single context might include both backend and frontend components (like an Appointments Search Context), while another could be backend-only (such as SMS/Email Notifications, communicating via kafka messaging, whichever fits), depending on its specific responsibilities.
Certainly, a UI component might need to talk to a legacy backend or even an external one (like a payment processor or a mailing service). But often, a backend façade or BFF exists (or should exist) to mediate with those external systems. That layer would handle issues like ensuring a patient doesn't receive duplicate messages, even when network or system failures occur.
Regardless of the specific scenario, you define module boundaries from a strategic, high-level viewpoint—never just from the frontend's perspective alone.
Yet the frontend is never an independent Bounded Context. This is a surprisingly widespread misconception.
It's often what leads developers to invent "frontend-DDD" and go hunting for aggregates within the frontend landscape (spoiler: they won't find them there, because the frontend isn't concerned with persistence).
They might, for instance, mistake HTML form handling for DDD aggregates. That line of thinking doesn't hold up, since client-side code handles HTTP/WebSockets, not persistence, consistency, or transactions. Even if you use SSR frameworks like Next.js, which processes forms via server actions, you might have an aggregate on the server—but not on the client. And that brings us right back to where we started 🥹
As you can see, DDD is fundamentally tech-agnostic.
Ubiquitous Language and Meaning
When teams work on a product with a complex domain, they need to exchange sophisticated ideas. Specialized vocabulary becomes necessary. Think of Ubiquitous Language as a shared dictionary—maybe documented, maybe just commonly understood—that pins down precise terms.
For example, a specialist is any professional qualified to deliver medical services to patients. This includes "doctors" primarily, but also "nurses", "technicians", and various other professions.
We deliberately avoid using "specialists" and "doctors" interchangeably, to steer clear of ambiguity. In our context, a specialist is simply a specialist, full stop.
Ubiquitous Language is "ubiquitous" in the sense that it appears throughout conversations, in code, and in tests. But it is NOT company-wide; it's specific to each Bounded Context.
Why is that?
Consider that we run both B2B and B2C services, which operate in entirely different ways.
Now, who exactly is a Customer? Is it a single person (B2C) or an organization (B2B)?
Would it be sensible to build a Unified, Universal Model (also known as a Canonical Data Model) for Customer that spans the entire application?
That question deserves its own write-up (let me know if you'd be interested), but the short answer is: ABSOLUTELY NOT!
So what's the connection between a Customer and a Patient? Do these models coexist within one context, or are they exclusive to different ones?
When does it make sense to talk about a "Patient" versus a "Customer"? Perhaps Patient applies to Appointment Search and Scheduling, while Customer is for Billing and Invoicing—or maybe some other split works better?
The Customer should have a TAX ID. The Patient should have a Social Security Number (or the local equivalent). Does the TAX ID matter when booking an appointment? Does the SSN matter when sending an invoice?
Where do we draw the line between these models?
🔥 This is DDD. 🔥 This is its very essence. 🔥
How much of this has to do with Nx Monorepos, NGRX Global or Component Store, Signals, or specific service styles?
It simply doesn't.
Think of Semantics as the very first, foundational step in DDD. It's about breaking free from whatever your database or client-store data model looks like.
To put it in more formal terms:
A Bounded Context is a SEMANTIC BOUNDARY where a Ubiquitous Language is valid.
😅
Outside of its Bounded Context, a given term can mean something entirely different.
So, who is a patient?
From the appointments perspective, it's someone who uses our resources. Sad but true 😅
From the billing perspective, it's someone who pays for our services (directly or indirectly).
From the referral program perspective, it's someone who attracts new customers (and revenue).
From the perspective of unexpected events, a patient is a "problem," because we have to reschedule their appointments if a doctor suddenly becomes unavailable. And we probably don't automate that fallback, as it would severely harm the user experience (would you trust a machine to reschedule your visit without asking you first?)
And so it goes. Each Bounded Context is defined by its own specific semantics. Across different contexts, you might encounter a handful, or even dozens, of different representations of what the Patient is. That's perfectly normal.
(This is also, incidentally, a reason why you might not want to use centralized state management on the frontend, as these tools often normalize client state, which undermines module autonomy. In short: connect modules via EVENTS, not via STATE—but that's another topic for a different article).
Tactical DDD on the Frontend? No Thanks
Naturally, there's an entire separate discipline: Tactical DDD.
Very briefly, it concerns the specific design patterns we apply to realize DDD. This, too, warrants separate articles, but to summarize:
- Entities - define business objects that change over time and thus have identities (IDs).
- Examples: specialist, patient, customer.
- Value Objects - immutable data values.
- Examples: price, visit duration.
- Aggregates - the most crucial one. It is NOT a graph of related objects, as some describe it. It is a consistency boundary for concurrent operations. Sounds technical, right? Indeed—you can gauge someone's DDD expertise by how they define aggregates.
- Example: multiple patients attempt to book the same specialist, at the same date and time, in the same location. Only one can succeed.
- Key point: concurrent access to a scarce resource (there may be a race among users/parties to grab that resource).
- Would there be an issue if several patients booked the same specialist/clinic/time slot? If so, how significant is that business problem? Can we tolerate small occurrences (and what defines "small" in this case?)
- Technically, consider an aggregate to be the smallest possible unit of data that lets you handle race conditions. You might need to federate or shard your database (complex domains typically come with high scale, meaning horizontal scaling). The aggregate relies on database transactions to ensure no business rules are violated.
- Quite a mouthful, isn't it? I warned you it's not simple... And, by the way, why doesn't Tactical DDD make sense on the frontend? Exactly—aggregates don't belong on clients, since they almost never deal directly with database, persistence, or concurrency.
- A very frequent mistake: aggregates are too large, or far too massive, making them perform poorly and enforcing unnecessary data integration (consistency) for data that doesn't need it.
- Another common error: there's no actual concurrent access to a resource. Take collecting patient feedback, for instance. One patient's feedback has no concurrency or race conditions with another's. So, you might not need an aggregate in many cases.
- Repositories - they retrieve data from, most likely, an RDBMS and construct a domain-friendly object graph, frequently as an aggregate. Crucially, the ORM/DB model can differ significantly from your domain model. A repository isn't meant to make direct DB calls; it likely sits atop some technical layer.
- There are more tactical building blocks, but that's likely enough for now 😇
These patterns are vital in certain backend Bounded Contexts (though not all—simple CRUD is perfectly acceptable for some backend parts, when that's what's needed). However...
In 99.99% of cases, that would be pure Accidental Complexity. You don't want that.
Incidentally, if you label Angular Services that just make HTTP calls as "Repositories," you're making your code appear more sophisticated than it actually is. Technically, it's not wrong, but semantically it probably is—the JSONs you fetch (contract DTOs) should already be shaped in a client-friendly way. A Repository's purpose is to adapt the server's model to your domain model, and that should happen on the backend, not the frontend.
Don't adopt fancy names just for their own sake—it doesn't benefit anyone.
Wrapping Up the DDD Vocabulary
Once you’ve worked through the DDD terminology, you could sketch out a diagram that looks something like this:
That’s a neat diagram, right? Now you might feel ready to claim you grasp DDD.
Sadly, THIS DIAGRAM WON'T GET YOU FAR when it comes to truly understanding DDD.
For reference, the original chart from the Blue Book is also available:
(quick note: that one doesn’t clarify the essence of DDD either — BUT 😅 — if you’re into reading, pick up the Red Book instead of the Blue one, since it’s far more beginner-friendly)
Someone wise once pointed out:
There’s a big gap between knowing a word and truly grasping its meaning.
From what I’ve seen, that gap is genuinely massive. It often fuels semantic diffusion. Folks toss around a term without really owning its meaning. It drifts from its roots. So when someone drops the term, what’s actually in their head? 😕
If you’re now convinced that sprinkling DDD vocabulary here and there, without putting in real effort, DOESN'T MAKE THINGS ANYHOW SIMPLER — then I’m totally satisfied.
Don’t jump to label yourself as doing DDD. It’s wiser to aim for being business-driven (not a buzzword yet), business-centric, or business-aligned.
Are you?
Monorepos: Unrelated to DDD
Now that we’ve got the basics of DDD down, let’s circle back to... Monorepos.
Regarding monorepos, how you structure your code in folders or repositories is purely separate from your business and domain concerns — though it can influence team efficiency (development and operations — note, DevOps isn’t about docker or k8s 😅).
But keep this in mind: splitting your business code into Bounded Contexts is meant to make them autonomous, not reliant on each other. The whole appeal of monorepos, on the other hand, is to make sharing easier on a larger scale, like avoiding CI/CD delays or lengthy build queues.
However, sharing chips away at autonomy. The more you share, the less autonomy your team, module, or context retains.
Be careful with what you share.
Monorepos are a double-edged sword.
It’s great that monorepo tools let us restrict who can import what (such as Nx Module Boundaries or ESLint Restricted Imports). But let’s rethink the issue... Why would you need module boundaries or restricted imports? Is it because people tend to import stuff they shouldn’t? If you didn’t dump the whole codebase (many modules from many teams) into one repo, would that problem even show up? 😜
From my consultancy and training experience, in most cases, folks try to share way too much. They end up having to fix issues they created on their own.
I’ve witnessed frontend monorepos being overused (used without need or incorrectly) much more often than being applied well for solid reasons. Not to mention CV-driven development. Though, some might strongly disagree, and we can’t settle it without digging into real case studies.
DISCLAIMER: Despite all that, monorepos aren’t inherently bad. They’re just a tool. But like any tool, use them carefully. Don’t pick them by default without thought.
Component Libraries
Sure, you might need to share a reusable component library. But there’s no one-size-fits-all fix. “It depends” on a ton of factors. If someone pitches a “universal solution that works everywhere” — run the other way. You’ll appreciate that advice later.
There are various ways to share UI libraries. A monorepo might work, but it’s not the only option.
Component Libraries are the top Frontend headache I’ve seen in large systems during audits. And the main culprit? People dump too much into them. Again, that’s a topic for its own article.
If you don’t agree with my take, check out Thinnest Viable Platform on TeamTopologies.com. You want your platforms small, not big.
But let’s steer back to the core subject...
There’s a quote from Eric Evans I’ve got to touch on:
[...] the most fundamental pattern of Domain-driven Design is probably the ubiquitous language. [...]
[A model] applies within a certain context, and that context has a definitely defined limit, [it's] a bounded context.
With those two ingredients, I would say, someone is doing Domain-Driven Design, and there are a lot of other practices that help solve more specific problems.
This quote often gets used as a blanket excuse for “doing DDD” as long as you’ve got ubiquitous language and bounded contexts.
By now, I hope we’ve made it clear that:
- Frontend isn’t its own separate Bounded Context
- DDD is a discipline that spans the whole product and organization
- Frontend-only DDD is a myth in architecture
- you can apply DDD on Frontend, but only if it’s part of your entire product.
Also, notice that... if you lean on the quote above and skip the real meaning of what ubiquitous language and bounded contexts are, you could justify calling almost anything DDD. Feel free to brand any context as “bounded.” Do the same with ubiquitous language. Quod erat demonstrandum.
Does that actually help anyone reach their goals? I seriously doubt it.
Does it impress people? Possibly... Unless you run into someone who really gets the topic — then you could come across as... pretty clueless.
🔥 True mastery is having deep knowledge of a subject, yet using plain words that everyone can relate to. 🔥
No point in flashy jargon if it brings no real value.
How the Community Reacts
Here’s the thing: experienced backend/DDD folks would probably sum up this article as: “ah, that’s pretty obvious, nothing new for me”. Because it is 🤷.
At the same time, all of this might blow some frontend folks’ minds, since it tears down what they believed DDD was.
That’s exactly how semantic diffusion spreads.
To wrap up — let’s return to the initial post and tackle the questions:
Pay attention to the question:
I want to start a new project in #Angular using Domain Driven Design.
Why?
Is your domain actually complex?
Do you have Domain Experts on hand?
How would you map out Bounded Contexts?
And “DDD in Angular” — what about the rest of the system?
DDD isn’t an architecture style like modular monoliths, onions, or hexagons. DDD might fit into those, for better or worse.
When an experienced DDD practitioner hears “I want to start a new project using Domain Driven Design”, these questions come to mind:
- a new project? Okay, but how well do you understand the domain? Are the domain issues likely to cause pain? Do you even know where the tricky parts of your system are?
- put differently: if it’s brand new, how can you be sure you already need DDD? DDD isn’t something you just “set up from the start.”
What are your thoughts/opinions about DDD in big projects?
What does your application actually do?
DDD isn’t about preference or trends. It’s a tool.
It’s not about project size either. It’s about whether your domain is complex — or not.
It’s about how much you can lean on “simple CRUDs”... or how many business processes you manage... or how many people work on the system at once, and how much they need to collaborate daily. What do they need to agree on (to integrate the system while keeping coupling minimal)?
Is it worth it?
Like with most things, some will answer “yes,” others “no.” It depends on what you need, your situation, your architectural know-how, and more. Luckily, there’s no shortage of experts in this space to learn from.
If you’re keen on picking up DDD, don’t hesitate to contact me, or check out the people I consider experts in the field. You might also want to explore my aDDDvent series.
Happy DDD learning!
