Questions about Clean Architecture?

Question

.NET

If I understand correctly, the core of an application developed using the Clean Architecture approach is Entities. Entities are business objects of the application and contain the most general and high-level rules. As far as I understand, it is not entirely correct to specify secondary keys in entities (for example, userId) and in general, entities are not models for ORM. It turns out that if the entity has a link to the user, we simply add a field of type User to it. There are no Ids, except for the Id of the entity itself. In this regard, I have a question, which I will try to describe in the following example.
Suppose you need to develop an application - a list of tasks. There are entities User (user), Task (task) and Tag (tag). Each task can contain a set of tags + each task is associated with a specific user. Task tags must not be duplicated. It turns out that in the code we will have something like this:

class Task {
    // ...
    public string Text{ get; private set; }
    public User Creator { get; private set; }
    public IList<Tag> Tags { get; private set; }
    // ...
    public void AddTag(Tag tag) {
        // есть ли у задачи такой тег: если нет - добавляем
    }
}

class Tag {
    // ...
    public string Name { get; private set; }
    // ...
}

In the above example, there is a problem: it turns out that in order to check that the tags are not duplicated, they must be unloaded from the database and mapped from the ORM model to the entity.
Actually the question is: if we are working with an entity that contains a collection of other entities, how to check the rules for collections without unloading all the data from the database?

Answer 1

There are two options.
The first is to unload the entire collection of tags from the database. In this case, such a decision would be quite justified. Since usually tasks, and anything in general, contain 3-5 tags, 7-10 at most, very rarely more. In this case, it is quite normal to make the Tags property of the Task entity and expect that all the tags of this task will always be there. Those. always load the collection of tags for the task when restoring the task from the database.
The second is to move the logic into Service. CA and similar architectures dictate only that the business logic (BL) should be primary, and everything else is secondary and adjusts to the BL. But they do not limit the means of expression, i.e. it is not necessary that the entire BL be in the methods of the entities. On the contrary, inside the entities there should be only simple logic, and everything that is more complicated is taken out in Domain Services.
For example, you can create a TaskService that has the AddNewTagToTask(Tag tag, Task task) method. Since this is a service, here you can have a dependency on the corresponding repository, and then you can check for the presence of a tag using it: if (!taskRepository.TaskHaveTag(tag)) { ... }
The second approach is used when the connected collection is very large, thousands or more elements. In this case, this is generally the only option.
But it is worth noting that if the second approach is chosen, then it is worth removing the Tags property from the Task entity. Because it would be a scam. Imagine that you decide not to download all the tags for a task, but to do a check through the service. But you are not alone in the project. Another programmer will see that the task has a Tags field and will try to use it as if it contains all the tags for the task. Therefore, in order not to create ambiguity, you need to remove the Tags property from Task.

Answer 2

I want a prooflink, from where such infa comes from that entities cannot be ORM models and have foreign keys. As for me, this is complete nonsense, because entities are just called the basic models of the subject area, which are often the mapping of tables from the database, and, accordingly, have foreign keys.
That is why the main ORM in .net is called the Entity Framework , and its models are called entities.
Here is the definition of the entity model:

Any fragment of the subject area can be represented as a set of entities, between which there are some set of relationships.
An entity is an object that can be identified in some way that distinguishes it from other objects. Examples: specific person, enterprise, event, etc.
An entity set is a set of entities of the same type (having the same properties). Examples: all people, businesses, holidays, etc. Entity sets need not be disjoint. For example, an entity belonging to the MEN set also belongs to the PEOPLE set.
An entity is actually a set of attributes that describe the properties of all members of a given entity set.

And finally here .

Answer 3

In the orm of my dreams, it would be possible to formulate integrity conditions in the main PL (like linq) and they would be translated into sql. I don't know how on real orm