Fast Code, Fragile Systems!
Why domain thinking, business context, shared language, and clear boundaries still matter in the age of AI?
20 years ago, while working at Oracle UK’s headquarters, I spotted a colorful book on my colleague’s desk. I was lured by its artistic cover!
Domain-Driven DESIGN: Tackling Complexity in the Heart of Software by Eric Evans was that book — the Blue Book, as it is fondly called.
Little did I know that two decades later — after reading it twice — I would still be talking about it and urging every organization to adopt it.
The impact of Domain-Driven Design on the industry is immeasurable. Yet, modern engineers, in their pursuit of fast-tracked careers in cloud and now in AI, never read, understand, or apply it.
Unarguably, AI offers speed, but does it promote engineering discipline?
Are YOU an Agent? series:
Part 1: Who made Aaron redundant?
Part 2: AI Boom or Career Doom?
Part 3: Are You A Systems Thinker?
Part 4: This article
In the previous article, Are You A Systems Thinker, I discussed why complex problems require a holistic approach drawing on knowledge of the different parts of a system and their interactions.
While Thinking in Systems helps you view the parts and their dependencies, the art of breaking a problem into multiple solvable parts remains a challenge many in the software industry face. Abstractions, frameworks, tools, and other aids, such as cloud, serverless, and LLMs, are available and offer faster development and delivery, but they seldom help with organizational complexity.
If business complexity is not addressed, no matter how advanced the tools you use are, it will multiply and push you into a daunting, unrecoverable state. This is where Domain-Driven Design serves as your advisor and guide, showing ways to untangle business complexity and thereby establishing the boundaries within which AI and other developments can thrive.
Untangle business complexity before tackling engineering complexity, not vice versa.
What is Domain-Driven Design?
A domain is an area of interest, a sphere of knowledge or influence, or an area over which someone or something has control. For example, insurance is an area of interest in business. So are retail, computers, education, and media.
Domain-Driven Design (DDD) is a way of building software systems that focuses on the problem domain before implementing the solution.
DDD reiterates the importance of a shared understanding of the problem space among everyone, from the stakeholders to the developers, by using a shared vocabulary, i.e., ubiquitous language.
Every business consists of various parts or divisions to improve operational efficiency, manage complexity, and protect trade secrets. For instance, a toy company’s product design division is its core, while the human resources (HR) and finance teams support it.
Therefore, DDD proposes dividing a business domain into three subdomain types: Core, Supporting, and Generic.
Core Subdomain
The core subdomain represents the most critical part of the business. It differentiates the business from its competitors. It has the highest business priority and contains complex business rules, algorithms, formulas, or processes that are difficult to replicate.
For an online retailer, product recommendations can be a key differentiator through unique algorithms and personalization logic.
Given its significance, the core domain usually attracts the necessary investment and the best talent. Its criticality also warrants best-in-class technology, with solutions mostly built in-house.
Supporting Subdomain
Supporting subdomains serve as helpers or enablers for the core business. Though important, they are not unique to a single business. The complexity of supporting subdomains varies, but it is not as complex or critical as that of the core subdomains.
A customer service center or help desk is an example of a supporting subdomain.
Organizations rarely build in-house systems for this purpose. Instead, they opt for off-the-shelf applications or software-as-a-service (SaaS) with the required level of customization.
Generic Subdomain
As the name suggests, a generic subdomain represents common functionality across many organizations, a commodity with no competitive edge.
Take email services, for example. Microsoft Outlook or a similar service is used throughout the industry.
Low-investment, standardized, and off-the-shelf applications are the strategy most organizations use.
Model and boundaries
A domain model is a structured representation of the business, comprising data entities, objects, and aggregates, among other elements, and it uses a shared vocabulary (ubiquitous language). The system development will closely align with this model.
However, the meaning of a domain model and its elements varies across different parts of a business — often even within a single subdomain — depending on the context. For example, in an ordering system, an order refers to a customer purchase, whereas in shipping or dispatch, it refers to a delivery package.
A bounded context, therefore, is an explicit boundary within which a specific domain model applies. It helps manage complexity by encapsulating business rules, logic, and data for a specific area, enabling modularity and independent (autonomous) team ownership.
Beyond the main concepts outlined above, DDD encompasses many other essential concepts for software development. Learning Domain-Driven Design (O’Reilly 2021) by Vlad Khononov is a great book that I found useful.
Divide and conquer is a strategic problem-solving framework that breaks a large, complex challenge into smaller, manageable pieces.
Why is DDD Essential in the AI Era?
DDD is not another coding pattern or a best practice. Rather, it is a way of thinking about (problem) decomposition and (managing) complexity — the two most challenging yet interrelated tasks software engineers face.
From the book The Philosophy of Software Design by John Ousterhout:
The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it into pieces that can be solved independently.
Are you a thinker or a mere AI facilitator?
As a software engineer, when you partner with AI to automate processes and achieve speed, beyond the lengthy prompts you write and the agents you create, you become a facilitator — not a thinker. You must be mindful and cautious about transitioning into this role.
While AI brings several benefits across the industry, many fear and voice concerns about the loss of ingenuity among engineers. Perhaps it is a broader problem, not just in software engineering, as the following report suggests.
Norway imposes a near ban on AI tools for elementary school kids
Norway is imposing a near-total ban on the use of generative AI by elementary school pupils while restricting its usage…cybernews.com
Systems Thinking, as discussed in the previous article, helps you create a holistic view of the software application you help build.
Domain-Driven Design, on the other hand, allows you to separate business concerns, enabling you to build an evolvable software system. Your knowledge of DDD is therefore an essential trait alongside advances in AI.
As a software engineer, keep these points in mind when using AI to develop software systems.
Problem decomposition applies at all levels in software development.
Managing complexity is critical in any era of technology.
The speed of AI-assisted development demands stronger guardrails.
Understand how AI adoption varies across business subdomains.
1. Problem decomposition applies at all levels, from business to development
A good software system aligns with its domain and serves its purpose. When clarity starts at the domain level, it is easier to carry it through to the implementation level. The danger is that when teams — intentionally or otherwise — muddy clarity with modern tools and agents, systems become fragile and irreparable.
AI accelerates how you build; DDD ensures what you build — the right thing, the right way.
2. Managing complexity is critical in any era of technology
Though complexity cannot be avoided, it can be controlled or managed. The danger with AI is that complexity can multiply quickly if left uncontrolled.
Bounded Contexts help you manage complexity and reduce cognitive load through clear boundaries and ownership.
The Cynefin Framework helps you understand challenges and make decisions. As an engineer, when you use AI, you must always evaluate whether your complex system is degrading into a chaotic state or improving toward a clear state.
Be vigilant about whether AI introduces essential (necessary) or accidental (unintended) complexity to your system.
3. The speed of AI-assisted development demands stronger guardrails
Several teams that boarded the runaway AI train without a second thought are already grappling with messy, unmaintainable codebases. This is the undoing of all the good development practices learned over the years, resulting in a modern big ball of mud.
Therefore, domain classification, clear communication, ownership boundaries (bounded contexts), human-in-the-loop processes, and governance are all critical to realizing the benefits that AI brings.
Speed without guardrails is a disaster waiting to happen, whether in life or in AI-assisted software development.
4. AI adoption varies across the subdomains
Luca Mezzalira once stated that business domain classification always mattered for architectural decision-making.
In a business, not all domains are the same. As discussed earlier, subdomains vary, and so do their technology needs. Hence, AI adoption also differs between these subsystems.
As a technical contributor and influencer in your organization, you must provide the necessary direction on where and how to adopt AI.
To Conclude on Domain Thinking…
Undoubtedly, the world continues to witness several benefits from the advancement of AI. On the other hand, the mad AI rush also blinds teams into neglecting proven development practices, leading to a chaotic, fragile, and unrecoverable situation. This, in turn, necessitates deploying more AI agents to untangle the mess, thereby trapping them in a continuous loop.
As a technical contributor, you must know how to use AI to achieve both short-term tactical gains and long-term strategic business goals.
Domain-Driven Design complements AI-assisted development to build the right thing the right way. Domain boundaries and modularity are essential to building evolvable systems, regardless of the tools and technologies.
As the article The Review Bottleneck: Rethinking Software and Infrastructure Design for the Agent Era concludes,
The teams that win with agents will not be the ones with the best prompts. They will be the ones with the best boundaries.
Data is the soul of Generative AI, the superfood that enables algorithms to work their magic. In the next article, I will discuss why Data Thinking is critical for a software engineer to thrive in AI.