Nice to meet you.
I've studied DDD and clean architecture to some extent, and I've kind of figured out what role each object plays.
However, when you try to design a real service with a DDD+ clean architecture, you don't really know what the domain model will be.
I'm thinking of an Instagram-like site as an example.
Implement a use case called "View User Profile".
This time, we will use icons, posts, followers, followers, names, descriptions, links, and a list of photos posted.
There are two types of profiles that you can view: your own profile and the other person's profile, showing the date of registration for your profile, and whether you are following the other person's profile.
First of all, in this case, the user's interest is in the profile, so I thought the profile would be one domain model.
The profile is not based solely on the user's registration information, but also on the photos you posted.
Therefore, I think the profile is aggregation based on user entity as root.
However, I have no idea how to drop it into a model any more.
I can think of users and photos as an entity...
I have no idea what the domain model of profile is, how it behaves, and what use cases do.
I think you'll be able to feel it after looking at the actual design pattern over and over again...
In this case, please let me know what kind of design it should be.
domain-driven-design
"The use case of ""viewing data"" does not show much domain behavior, so if you use it as a subject, you will probably get stuck like a questioner."
As you can see from keywords such as "DDDCQRS", domain models are powered by update processing.
The profile is not based solely on the user's registration information, but also on the photos you posted.
Therefore, I think the profile is aggregation based on user entity as root.
Even if it's a profile picture, the photos posted on the photo sharing site should be aggregated differently from the profile.
Aggregation is a boundary, transaction boundary, that must be consistent.
I think the transaction boundary between profile and posted photo is different.
For example:
[Profile] entity (aggregate route)
+ User ID
+ Name
+ Self-introduction
+...
ユーザThe current information alone cannot determine whether the concept of user and profile should be different models...
[Post Photo] Entity (Summary Route)
+ Post Photo ID
+ User ID of the contributor
+ Name
+...
*I think it is better to save the image data of the posted photo itself to a different storage and have only an ID in the domain
This time, we will use icons, posts, followers, followers, names, descriptions, links, and a list of photos posted.
I mentioned the word CQRS earlier, but the information you can see on the profile screen and the attributes that the profile entity should have do not always match.
I think it would be better to prepare a query that is separate from the domain model for the number of posts and followers.
Doing so will not affect the domain model if you do a lot of things for performance, such as providing a separate table for queries and returning aggregated information such as periodic batches.
@mok2pok wrote a very good answer, but
I didn't understand it at first glance, so I asked for additional information.
CQRS is a Command and Query Responsibility Segmentation pattern, one of the architectural design patterns.
Browse: https://msdn.microsoft.com/en-us/library/dn568103.aspx
An attempt to avoid the complexity that occurs when the model must consider both read and write by separating the command (update processing) and query (reference processing) models.
As @mok2pok said, when used with DDD, a thin Dto is prepared to eliminate the logic of loading.
© 2024 OneMinuteCode. All rights reserved.