A Pragmatic View of Domain-Driven Design

Domain-driven design (DDD) is a set of software design principles that are widely used in modern enterprise applications. They were bundled and made popular in 2003 by Eric Evans in his book Domain-Driven Design.

You might be wondering how this is related to test-driven development (TDD). Is it because it is a similar-sounding acronym? The reality is that TDD and DDD work together where TDD covers the design from the client’s perspective and the quality, while DDD complements the rest of the design. You will hear the two terms used together in a conversation and in job specifications, and the reason for this will be clear by the end of Part 2, Building an Application with TDD.

This chapter is meant to be a primer on DDD, so you will have the foundation required to build a complete application using a combination of TDD and DDD.

DDD is a technical and a philosophical topic. Given the pragmatism of this book and the length of...

Technical requirements

The code for this chapter can be found at the following GitHub repository:

https://github.com/PacktPublishing/Pragmatic-Test-Driven-Development-in-C-Sharp-and-.NET/tree/main/ch07

Working with a sample application

We need a sample application to demonstrate DDD concepts. The word application can have various meanings in your project. It can be one of the following:

• A single microservice that is part of a larger application
• A monolith application that is a standalone application

This chapter will use a monolith application, as it is easier to explain the concept and the context will be clearer. So, we’ll focus on the specifics of DDD rather than diverging into a more complex architecture.

Let’s take a blog application as an example. A DDD-style blog application might look like this in Microsoft Visual Studio (VS):

Figure 7.1 – A blog application in VS

UQS is our fictitious company’s initials, standing for Unicorn Quality Solutions. These projects have the following dependencies on each other:

Figure 7.2 – Project dependencies

Nothing special here: this is...

Exploring domains

DDD is a collection of software design philosophies and best practices. There are a handful of books dedicated to DDD, and most of them are above 500 pages. So, we can talk a lot about DDD, but this book isn’t about DDD, so we will be brief.

DDD focuses on business logic and the interaction with the DB and the outside world and employs a set of practices for a robust software design. The word domain in DDD refers to a business domain, which can be car insurance, accounting, billing, banking, e-commerce, and others. DDD emphasizes the business domain, as per the term domain-driven.

Next, we will explore the architectural components that make the practical aspect of DDD.

Domain objects

A domain object is a representation of a real-life business entity. Exploring our blog project, the domain objects can be like this:

Figure 7.4 – The classes and structs contributing to a blog domain

You can see how the names of these...

Exploring services

Services in DDD are divided into three types, but we will focus on the domain services for now, and then we will discuss the other two later: infrastructure services and application services.

A domain service is the unit within the DDD ecosystem where the business logic lives. A domain service has the following responsibilities:

• Loading domain objects through the help of repositories
• Applying business logic
• Persisting the domain objects with the help of repositories

It is important to understand that the domain services are unaware of how the data is loaded from the storage medium and how it is stored. They only know how to request a data-loading or persistence operation through the help of data repositories. Repositories will be covered later in this chapter.

Let’s add some services for our blog project to help us with publishing posts, and retrieving and updating them.

Post management

If you have ever published a blog...

Exploring repositories

Repositories are classes that belong to infrastructure. They understand the underlying storage platform and interact with the specifics of the data store system.

They should not contain business logic, and they should only be concerned with loading and saving data.

Repositories are a way of achieving a single responsibility (as in SOLID’s single responsibility principle) by having the services and the domains responsible for business logic but not responsible for data persistence. DDD gives the data persistence responsibility to the repositories.

An example of a repository

You’ve seen this line of code previously in the UpdateTitleService class:

var post = _postRepository.GetById(postId);

Here, we will show you a potential implementation of GetById.

Using Dapper with SQL Server

Dapper is a .NET library categorized under the term micro-ORM. It is very popular and used in StackOverflow.

Dapper can be used to access a SQL...

Putting everything together

This is my favorite part. I have been providing little snippets here and there and, hopefully, now you can see the big picture of how everything is linked from a DDD point of view. I have included the snippets in the source code directory.

Solution Explorer view

What we’ve done in this project is a collection of snippets. Let’s have a look at them:

Figure 7.5 – VS solution files from a DDD perspective

Let’s have a recap of every item:

1. Contracts: This is what the outside world sees. These contracts represent the shape of the data that will be exchanged between the backend and the client. The client should know the data elements of the contract, so it knows what to expect from your headless blog.
2. Entities: They are the domain objects with identities.
3. Value Objects: They are the domain objects that don’t require an identity.
4. Domain Objects: This is the group of entities and...

Summary

There are topics in DDD that I have omitted, as they don’t contribute directly to the rest of the book, such as bounded contexts, domain events, units of work, and others. I have provided additional resources in the Further reading section that will help you to explore the concepts further.

We have discussed the basics of DDD and I am expecting this chapter to make you familiar with this concept, so we can use the terms such as domain objects, domain services, and repositories freely in later chapters without you raising an eyebrow. We have also seen sample code of the different constituents of DDD.

We have also seen where we will shift from DDD guidelines where it is more practical to do so and explained why.

In the next chapter, we will set a foundation for a complete project that will utilize all that you’ve learned so far, including DDD.

Further reading

To learn more about the topics discussed in this chapter, you can refer to the following resources:

• Domain-Driven Design by Eric Evans, Addison-Wesley (2003)
• Implementing Domain-Driven Design by Vaughn Vernon, Addison-Wesley (2013)
• Hands-On Domain-Driven Design with .NET Core by Alexey Zimarev, Packt Publishing (2019)
• Design a DDD-oriented microservice: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
• Martin Fowler on DDD: https://martinfowler.com/bliki/DomainDrivenDesign.html
• Quickstart: Build a console app by using the .NET V4 SDK to manage Azure Cosmos DB SQL API account resources: https://docs.microsoft.com/en-us/azure/cosmos-db/sql/create-sql-api-dotnet-v4
• Dapper on GitHub: https://github.com/DapperLib/Dapper