What is Domain object and Subject area, in simple terms?

Question

OOP

I started to study OOP and I often see the mention of the Domain object and the Subject area . I see them especially often in the context of the Repository . Because I am not yet ready for a complete immersion in the books of Evans and Vernon. Many articles were read and, selectively, chapters from these books. Unfortunately, I did not quite understand, even superficially, what they are. I will describe how I understand these concepts, I will ask you to correct me or supplement.
Subject area - represents a part of the real world that should be implemented in our system.
Example:

1. Blog - creating and publishing
   
2. Human Resources - Employee Accounting
   
3. Auction - sale of goods
   

Domain object - represents the main significant entities that belong to the subject area. A class that describes the main attributes and possible behavior.

1. Blog:
   
   • Write/Post
     
   • Reader/User
     
   • Comment
     
   
   
   
2. Human Resources Department:
   
   • Employee
     
   • Subdivision
     
   
   
   
3. Auction:
   
   • Product
     
   • Buyer/User
     
   
   

A domain object that contains nothing but attributes, getters and setters is called Anemic and is an antipattern.

class Account
{
    private Id $id;
    private Balance $balance;
    private Status $status;
    private array $clients;
}

The domain object must contain all the business logic for working with this object.

class Account
{
    private Id $id;
    private Balance $balance;
    private Status $status;
    private array $clients;


    public function addClient(int $id);
    public function removeClient(int $id);
    public function rechargeBalance(int $amount);
}

Also interested in what "domain object level" and "domain model level" mean. Mentioned on the wiki

Answer 1

The subject area is the set of all entities and their relationships within the context.
For example:
Within a store, these are buyers, sellers, products, prices, discounts, suppliers, the process of selling, coming to the warehouse, returning, etc.
Within the discord, these are users, servers, rooms, groups, access rights, the processes of joining a server, entering a room, paying for nitro, writing a text message, etc.
In general, this is everything that your manager understands and nothing that he does not understand. The subject area does not include, for example, where exactly you store data - in mysql, in files, you receive and save them via API or store them in redis. But the abstract entity "storage" is included. It is also the interface of the repository. A repository is a pattern that hides the implementation of a specific repository and that operates on domain model objects - domain elements, as if they were stored in your RAM. For example, a repository might have methods

users.getByID(1234), users.save(user), users.getByEmail("[email protected]")

etc. The implementation of the repository determines where exactly this user will be saved or where it will be downloaded from. In one table or in several. Whether the data will be normalized in the RDBMS or denormalized. It is here that you can implement writing to master, and reading from replicas. Or encoding in msgpack and transferring it via API somewhere. Or via gRPC. Because the subject area should not be overloaded with implementation details of storages.
About the domain model:
A dictionary (also known as a hash, or an associative array) is not a domain model (although it may be in some functional languages). The ORM object is also not a domain model, although there are many places where it tries to be. The domain model does not depend on specific frameworks, databases, optimizations of these databases, and other imposed technical entities. Most often, this is a regular class in the language in which the code is written (or struct in the case of Golang).
Recent example:
An entity has tags by category:

{"category1": ["foo", "bar"], "cat2": ["foo", "hello", "world"]}

. It is so convenient to represent them at the level of the subject area, I can communicate with the customer about this structure. But in monge they are saved as

['category1%%foo', 'category1%%bar', 'cat2%%foo', 'cat2%%hello', 'cat2world']

, because it's easier to index them and search them faster. But this is hidden in the implementation of the repository, the domain area does not know anything about it. This gives many advantages at once:
1. It is very easy to test, without any mocks. Instead of a repository with monga, I make a repository that stores entities in the operative. That's it, business logic tests do not depend on the infrastructure. And I test the monga repository separately, mooching requests to the monga itself or not even mokaying
2. It makes the whole product easier to understand. The brain does not try to make a complete picture, when queries in the database are mixed with logic, then there are split-joins of lines, some other low-level actions. It is easy for the brain to navigate within the level. At the repository level, I think about how entities are stored and retrieved from the repository, at the service level, I think about how entities interact and which ones need to be retrieved / stored, but not how
3. Refactoring is very simple. Even a theoretical database change. Tomorrow you will need to transfer one entity from Mongi to Postgres - no problem. I will write one new repository without affecting a single line of code outside of it, except for the place where it is created. At the same time, the rest of the entities can still lie in the mong
Domain models can be rich and anemic (but not bloodless). Both approaches apply and, IMHO, neither is an anti-pattern. Personally, I use anemic models, and I store all business logic in services.