Domain-Driven Design: Bridging the Gap Between Business and Technology

In today’s fast-paced world, businesses need to be agile and responsive to changes in the market. That requires software systems aligned with business needs that adapt quickly to new requirements. Traditionally, software development has been a primarily technical exercise, with development teams focused on writing code and implementing features based on imposed requirements without necessarily understanding the business domain. That often fails to meet those needs, resulting in costly mistakes and delays. That’s where Domain-Driven Design (DDD) comes in. Unlike traditional software development approaches, which focus on technical aspects, DDD strongly emphasizes understanding the business domain and modeling it in the software. By doing so, DDD can help bridge the gap between business and technology.

What is Domain-Driven Design?

DDD is a software development approach first introduced by Eric Evans in his book “Domain-Driven Design: Tackling Complexity in the Heart of Software” (2003). At its core, DDD is about creating software systems closely aligned with the business domain and its needs.

In DDD, the business domain is the central focus of the development process. A business domain, often called a “domain” for short, is the business area the software system is being developed to support. It is a distinct and well-defined business area with its language, processes, and rules. Sometimes, a domain may be broken down into smaller subdomains, more specialized areas within the larger domain, for example, invoicing, shipping, and orders subdomains in an e-commerce business domain.

Ubiquitous Language is a shared language used by everyone involved in software development, from business stakeholders to developers. It is a common language specific to the business domain and consistently describes concepts, processes, and ideas. This language omits technical jargon and focuses solely on particular business terms used by the company or organization. By establishing a Ubiquitous Language, developers, and business stakeholders can communicate more effectively and work together to develop a software system that meets the needs of the business. This shared language can also help identify system areas that need improvement or refinement, leading to a higher-quality end product.

Developers work closely with domain experts, such as business analysts and subject matter experts, to understand the business domain deeply and identify the key concepts and relationships relevant to the software system. This understanding is then combined into a set of well-defined building blocks known as “domain models” used to model the business domain in the software. Domain models are the cornerstone of DDD. They represent complete knowledge about the business domain, including key concepts, relationships, and rules. They also provide a common language for developers and domain experts to communicate.

Domain-Driven Design: Bridging the Gap Between Business and Technology 1

Bounded contexts are another important concept in DDD. They define a specific area of the business domain within which a particular model is valid. A bounded context is a boundary around a specific subdomain that represents a clear separation from other subdomains in the same business domain. That helps ensure that models developed for one bounded context do not interfere with those developed for another. For example, in an e-commerce platform, the bounded context for the shipping subdomain may differ from that for the order subdomain. By defining clear boundaries around each subdomain, developers can ensure that the models developed for each subdomain are cohesive and consistent, leading to a more robust and maintainable software system.

Domain-Driven Design describes two distinct types of design: strategic and tactical. Strategic and Tactical Domain-Driven Design (DDD) are two complementary approaches to software development that help ensure the business domain is the central focus of the development process. Strategic DDD involves identifying the key business domains and subdomains and developing a high-level plan for how the software system will support them. This plan includes identifying key business capabilities, defining bounded contexts, and identifying domain relationships. Tactical DDD, on the other hand, focuses on the implementation of domain models within bounded contexts. It involves breaking down the high-level plan into smaller, more manageable parts and developing the software system using well-defined domain models.

Benefits of Domain-Driven Design

There are many benefits to implementing DDD in your software development process. First and foremost, DDD can help improve collaboration between business and development teams. You can ensure everyone is working towards the same goals by aligning your software systems with your business needs. That can help improve communication, reduce misunderstandings, and create a more collaborative working environment. It brings enormous benefits in terms of efficiency, as the development team doesn’t have to translate business requirements to understand them, and vice versa – the business understands questions and concerns brought by the developers.

Another benefit of DDD is improved software quality. By focusing on your business domain, you can create software better suited to your needs. That can lead to fewer bugs, faster development cycles, and a more efficient software development process.

Finally, DDD can help you achieve your business goals. You can create software that enables you to achieve your strategic objectives by aligning your software systems with your business needs. Whether you want to improve customer satisfaction, reduce costs, or increase revenue, DDD can help you get there.

Domain-Driven Design: Bridging the Gap Between Business and Technology 2

Uber’s adoption of Domain-Driven Design: A case study

The ride-hailing titan Uber has effectively implemented Domain-Driven Design as it transitioned from a monolithic architecture to a more flexible, scalable microservice architecture. However, the transition wasn’t entirely devoid of challenges. As Uber’s services expanded to around 2,200 critical microservices, the complexity they introduced became significant. Uber’s innovative solution to this was the introduction of a “Domain-Oriented Microservice Architecture” (DOMA), a model deeply influenced by Domain Driven Design and other established architectural paradigms, such as Clean Architecture, Service-Oriented Architecture, and object- and interface-oriented design patterns.

Uber’s implementation of DOMA grouped microservices into logical entities called domains, which could consist of one or multiple microservices. The size of these domains wasn’t prescriptive but rather dictated by the logical role each collection played, for instance, map services, fare services, or rider-driver matching services. Notably, the organization of these domains didn’t necessarily follow the company’s organizational structure, reflecting the dynamic nature of the company’s architecture.

Uber also established a layered design within DOMA, which helped manage service dependencies, mitigating the impact of an outage and controlling the failure blast radius. The layers ranged from generic, underlying business functionality like account management to more user-specific experiences, like mobile features. This layered design also offered a clear path for features to move “down” from specific to more general, which
became more critical as Uber expanded its business lines like Uber Eats and Uber Freight.

Furthermore, adopting the Gateway API concept was central to Uber’s DOMA. This provided a single entry point into each domain, reducing system complexity, enhancing future migrations, and improving discoverability. Uber also introduced extensions as a mechanism to expand domains without altering the underlying service’s implementation, further promoting domain autonomy. Extensions ranged from logic extensions that extended a service’s underlying logic to data extensions that allowed arbitrary data to be added to requests without bloating the core platform’s data models.

Uber’s DOMA architecture has reaped substantial benefits for the company. It resulted in order of magnitude reduction in platform support costs, a decrease in new feature onboarding time by 25-50%, and facilitated a system where multiple teams can operate independently. It also eased the process of migrating and refactoring legacy services. The implementation of DOMA at Uber highlights the importance of structured, logical domain orientation in managing and reducing system complexity within a large-scale microservice architecture.

The future of Domain-Driven Design: Emerging trends and developments

Domain-Driven Design (DDD) has been around for nearly two decades and has proven to be a valuable approach to designing and developing complex software systems. As the field of software development continues to evolve, DDD is also becoming to meet the changing needs of businesses and developers.

One emerging trend in DDD is the increased focus on event-driven architectures and reactive systems. These approaches allow for more flexible and scalable systems that can better handle the demands of modern applications. DDD practitioners are exploring incorporating these concepts into their designs to create more resilient and responsive systems.

Another trend in Domain-Driven Design is its application to machine learning and artificial intelligence. DDD provides a robust framework for understanding complex domains and aligning software systems with business needs. By applying DDD principles to machine learning, developers can better understand the problem domain and design more effective machine learning models.

Last but not least, there is a growing recognition of the importance of collaboration between business and development teams in the DDD process. This collaboration is essential for ensuring software systems align with business needs and evolve to meet changing requirements. As such, there is an increased emphasis on techniques such as event storming and domain storytelling that facilitate this collaboration.

Domain-Driven Design: Bridging the Gap Between Business and Technology 3

At Applandeo, we are committed to delivering high-quality software solutions for our clients. We invest heavily in our team’s training and development, ensuring they are always up-to-date with the latest trends and technologies. We prioritize picking the tools and methodologies best suited to our clients’ needs. Our dedication to exceptional customer service means working closely with our clients to understand their unique needs and delivering solutions that meet or exceed their expectations.

Let's chat!

Domain-Driven Design: Bridging the Gap Between Business and Technology - marcel-100px Hi, I’m Marcin, COO of Applandeo

Are you looking for a tech partner? Searching for a new job? Or do you simply have any feedback that you'd like to share with our team? Whatever brings you to us, we'll do our best to help you. Don't hesitate and drop us a message!

Drop a message
Domain-Driven Design: Bridging the Gap Between Business and Technology - Start-a-project