How did I build a simple API using DDD?

DDD has been and is still a popular design trend in large, business-intensive systems at the moment. However, understanding the “academic” definitions of DDD is very time consuming, and to support programmers in general as well as those who are intending to learn about DDD in particular can withdraw In a short time to “absorb” the “academic” knowledge of DDD, I would like to present to readers very basic knowledge as well as illustrative examples through this series of articles on DDD, looking forward to well received by readers.

An overview of the API I’ve built

I built this API with the main purpose to practice more about DDD so I won’t focus too much on complex functions. Basically my API can be described using a usecase diagram as follows:

This is basically an API that allows users to:

• Create a post with an accompanying photo
• Comment / Like the post
• Follow / Unfollow other users

Readers can refer to my source code at: https://github.com/tuananhhedspibk/NewAnigram-BE-DDD-Public

In this API, I use two main technologies which are nestjs framework and mysql database.

What is DDD?

DDD (Domain Driven Design) is a way of designing “business-oriented” software – that will take the business (domain) as the center of the system.

Maybe with the system “banking” or “logistics”. If only talking about concepts, it will be difficult to imagine what DDD is, so in this article I will try to illustrate each concept of DDD corresponding to my API code.

Some basic concepts in DDD

Because it is “domain” driven design, domain is the main concept here. Revolving around the concept of domain, we have 3 main key words that are Domain , Model and Domain Model

Domain is a certain field of business such as “banking business” or “logistics business”, …

Modeling is the process of abstracting business objects and operations. This process of modeling business into abstract objects is called Modeling or Modeling .

Domain Models are the models we get after the above Modeling process.

Going back to the API above, my domain is người dùng có khả năng đăng bài và theo dõi các người dùng khác . I will model into 2 main models:

• User
• Post

these are also the two main “objects” in my API. To illustrate more clearly for the two models above, I have a Domain Model diagram as follows:

Looking at this diagram, readers can see:

• Basic post properties: content, imageUrls, …
• Basic properties of the user: email, userName, password
• 1-n relationship between User-Post

It is correct but still missing a lot, for example:

• Comment
• Like
• Theo dõi
• User detail (save details of the user such as: firstName, lastName, age, …)

Not only that in DDD we also have another very important concept that is Aggregate – Aggregation . Simply put, aggregate is: a collection of objects that are closely related in terms of data that we always have to guarantee.

Take for example the following:

A Club will have “Members”, here we specify that the status of the Club will be FULL if the value of memberCount = 5 , the status of the Club will be STILL_FREE if the value of memberCount < 5 . From this rule, we see that there is a close relationship between Club and Member in terms of data, so it can be concluded that Club and Member will belong to the same aggregate – aggregate (Note: from now on I will use the term aggregate). So the domain model diagram of Club and Member will be edited as follows:

Going back to the API I introduced, after considering adding Follow, Like, Comment and User Detail I decided to split the aggregate as follows:

Brief explanation is as follows: I divide my domain into 3 aggregates respectively:

• User
• Post
• Theo dõi

My API doesn’t have too many data constraints like the Club and Member examples above, but organizing by aggregate “units” will help the code represent the business more clearly.

I take the example of User Aggregate: in this aggregate I save the basic information of the user (email, password) and details (nickName, avatarUrl) of the user through 2 objects respectively User and UserDetail , here User will be called Root Aggregate or root aggregation.

One of the basic principles when working with aggregate is that the aggregate information can only be updated through root aggregate , which means that updating information for UserDetail or User must go through User Aggregate or in other words. is User Object .

You can see how I define User Aggreate at . You can see how I update UserDetail as follows:

I create an updateDetail method inside UserEntity class (this is User Aggregate class), this method will update user detail information so updating user detail will actually look like this:

And User aggregate will “aggregate” userDetail within it through the class’s property as follows:

Each method itself defined in the Aggregate classes will represent the content of the business that the system is modeling, in the example above, updateDetail .

Same analysis with Post Aggregate at source code . Post Aggregate with Post object as root aggregate , Comment & Like objects will be child objects “aggregated” inside Post Aggregate through class properties as follows:

As for Follow Aggregate , it is quite simple, it only has 2 unique properties:

• srcUserId: id of the user that is following.
• destUserId: id of the user being followed.

For more details, you can read it here

End of part 1

OK, so that’s a very basic and important concept of DDD that is Aggregate , hopefully through this opening article readers have absorbed some of the first “fingers” of DDD. Basically after this part I hope that readers can understand:

• What are domains?
• What is Modeling?
• What is Domain Model?
• What is Aggregate? What are the characteristics of Aggregate that deserve attention?

There is also a small reminder for readers that the two diagrams I presented above are Sơ đồ usecase and Sơ đồ domain model , I will not detail the definitions of these two types of diagrams, but Simply put:

• Sơ đồ usecase will show the main functions that the system will provide to the user (this diagram must precede the domain model diagram).
• Sơ đồ domain model will show how we model the objects in our business system. In this diagram, readers should pay attention to the following basic things:

1. The aggregate division is reasonable based on the actual business.
2. Specify the properties of the aggregate as well as its child objects (the method may not be required).
3. Full annotation of the business logic in the diagram (in bullet form).

Part 1 ends here, see you again in the next articles in the series about DDD, thank you.