Why Domain-Driven Design Is Not Just for Developers

In recent years, I’ve been actively promoting a mindset based on common sense, lean thinking, and a modern, flexible (in the good sense) product-oriented approach. One of the tools that has helped me the most on this journey is Domain-Driven Design (DDD).

Many people think of DDD as something strictly for developers. But I firmly believe it’s a collaborative technique above all. It’s valuable for analysts, product managers, architects, and project managers. But it’s especially important for those who are closest to the business side. Why? Because they’re the ones best positioned to build a bridge between the domain world and the codebase.

This article is about how to make that happen.

Domain-Driven Design: Not Just for Developers

If you’re a systems analyst, business analyst, product owner, or project manager, and you see the term Domain-Driven Design (DDD), it might seem like something “not meant for you” — more for architects or developers. But in practice, it’s often the analyst who becomes the key link between the business domain and the code. And that’s exactly where DDD starts to shine.

In this article — inspired by a live workshop with analysts — we’ll cover:

• What DDD is and why it’s relevant for real-world projects
• How to align with your team and stakeholders using a shared language
• What a bounded context is and why it matters
• How architecture works from a DDD perspective
• Why analysts benefit from understanding code
• How to analyze subdomains using examples from a restaurant and an edtech platform
• Recommended books and resources to go deeper into the topic

What Is Domain-Driven Design and Why It Matters

Domain-Driven Design (DDD) is an approach introduced by Eric Evans that helps teams create system architecture and code that reflect the actual business domain. It focuses on four main areas:

• Strategic design — understanding complex domains and identifying their key components
• Collaboration — establishing a common language among analysts, business stakeholders, and developers
• Architectural principles — designing systems, components, and interfaces
• Tactical patterns — working with entities, aggregates, repositories, and services

DDD is especially valuable for complex systems where traditional automation methods fall short. In digital products with a high degree of uncertainty, DDD helps reduce chaos and build clear, meaningful models.

It also significantly reduces misunderstandings within the team. When everyone speaks the same language and uses the same definitions, countless small and large conflicts simply vanish.

How Code Reflects the Domain

DDD not only impacts business logic but also influences the code itself. The goal is to make the code "speak" the language of the domain.

Here’s an example in C#:

var discount = CalculateDiscountBy(customerId);
order.ApplyDiscount(discount);
order.SetStatus(OrderState.AwaitingPayment);

This code is much more understandable than:

var d = Calc(1);
o.StateId = 1;

This approach allows even non-developers to understand what the function is doing. This is why it’s important for the analyst not just to pass on requirements but also to help shape the domain language that will form the foundation of the code.

Practice: How to Understand Simple Things in Different Ways

In the lecture, we reviewed a simple example: what is a "lesson", "listener", and "teacher". Participants gave dozens of different definitions. Some defined a lesson as "a process of transmission", others as "a structured lecture with a topic", and some as "a period of time with educational content".

This case demonstrates how important it is to fix definitions, even for simple concepts. This is where a glossary comes in handy.

A good glossary should be:

• Unambiguous (eliminates confusion)
• Self-contained (does not require cross-references to understand)
• Without recursive definitions (does not explain "hand" through "handiness" and vice versa)

Limited Context: Each Has Its Own Meanings

The unified language applies within a bounded context. This is a logical boundary within which terms have specific meanings. DDD directly states: there is no single language for the entire company.

Within each context, there are its own models, definitions, and objects. The same term (for example, "user") can mean:

• A client who filled out a form
• A registered user
• An active participant in the loyalty program

These contexts can (and should) be separated to avoid model conflicts and dependencies. In monolithic architectures, this is done by isolating modules, while in microservices, it is achieved by separate services.

Subdomains: Core, Supporting, and Generic

DDD distinguishes three types of subdomains:

• Core domain — the primary business domain that provides a competitive advantage. This area requires flexibility and high team involvement. It's important to remember that the core domain is not necessarily one thing. It can be multiple areas that make up the company's unique selling proposition (USP) — what the company earns money from, its know-how. This is why outsourcing the core domain is a very risky decision. There are cases where a company relied on an external contractor to develop the main functionality and ended up with a strong dependency on that vendor, or faced a painful and expensive transition. Internal expertise in these key areas is essential, because no one outside the company can assess business value as accurately as the company itself.

• Supporting domain — essential functionality that is important but not unique. It can be partially automated or use off-the-shelf solutions. This area requires more nuance: some functions might be very specific to your industry, and it makes sense to develop these in-house. Others, on the other hand, are easily available as ready-made solutions (e.g., CRM systems like HubSpot, Salesforce, Bitrix). These can be adapted to fit your process. The key is to understand where the boundary lies between unique and universal.

• Generic domain — typical components that are not business-specific. It’s better to buy or use as a service (e.g., accounting, document management, newsletters). There's no point in building your own accounting system if you just use it as a basic tool for accounting.

Important: The core domain should be developed internally because it defines your uniqueness. The generic domain should be outsourced. For the supporting domain, it’s wise to combine: buy some parts, develop others, and build your own where needed.

Cases: Educational Platform and Restaurant

Case 1: Online Course

• Core: Teacher, lesson (content and delivery)
• Supporting: Platform, schedule, personal account
• Generic: Zoom, payment system, registration

Case 2: Restaurant

• Core: Menu, technical specifications, orders
• Supporting: CRM, inventory, loyalty program, accounting
• Generic: Accounting, Zoom delivery, payment, supplier search

How Contexts Interact with Each Other

DDD offers patterns for context interactions:

• Shared Kernel — common code or model shared between contexts.
• Customer-Supplier — one context depends on another, using its API.
• Published Language — an open interaction schema (e.g., JSON schema).
• Anti-Corruption Layer — a layer between contexts that protects against "polluting" the model.
• Separate Ways — no connection between contexts.

These patterns allow systems to evolve independently, reduce coupling, and increase scalability.

What an Analyst Should Do: Tools and Steps

In the context of DDD, the analyst is the link between the business and development teams. Here’s what’s really important:

• Maintain a glossary — record all key terms that arise in communication with the business and the team. The glossary should be limited to the context you're working in. It can overlap with glossaries from other teams, but its purpose is to ensure a common language within your team. Everyone — from analysts to developers and product managers — should understand the terms the same way. The glossary should evolve as the project progresses.

• Use domain terms consistently — especially in documentation, emails, and calls. This might face resistance — people will want to use old names or personal abbreviations. Gently but persistently embed the domain language: use terms as agreed upon. If a term doesn't stick, discuss, rename, and agree again with the business. This is normal. The main thing is that everything is transparent and agreed upon.

• Create and maintain information models — the analyst is the first to document the appearance of new concepts and their relationships. The analyst can convey changes from the business to development. These models can take the form of class diagrams, ER diagrams, Miro or draw.io schemes — the key is that they are useful to the team. These diagrams should be used for synchronization with other teams to understand where and how you intersect.

• Help developers write readable code — the analyst doesn't have to write code but should be able to read it. If the code is written in the domain language, it will be understandable to the analyst and other team members. If you can’t understand what the code does, something might need improvement: naming, structure, readability. This is a collaborative space for analysts, developers, and architects. Don’t hesitate to get involved in discussions.

• Control terminology in the project — ensure that terms are used correctly and consistently. It’s also useful to compare your team’s terminology with other domains. For example, you may call an entity "contract," while a neighboring team calls it "agreement." This is fine as long as you understand that they mean the same thing. Such equivalences should be documented in a mapping between contexts. This helps integration, reduces errors, and eases synchronization.

DDD is not a one-time event, but a working culture, not a revolution, but an evolution. The analyst plays a key role in its formation and maintenance. First, you start using the same terms within the team. Then these terms infiltrate requirements and models. Then — into the code.

In Conclusion

Domain-Driven Design is not just about code. It's about understanding, structure, agreements, and mindset. It's a way to manage complexity in digital products. For an analyst, DDD is a tool that helps communicate with the team in one language, form a clear model, and ensure that the product reflects reality. Start small: create a glossary, discuss terms, clarify contexts. Water wears away the stone. And you'll be surprised at how much better everyone in the team will begin to understand each other — and you.