give the simplest example, such as a course management system, which has object types such as teachers, students, courses, classes and so on. Under the traditional anemia model, the service layer handles business logic, that is, it calls each object to add, delete, modify and query.
in ddd mode, the business logic is taken care of by the above entity classes, and the student chooses a course, which is initiated by the student, and the end result is an association between the student and the course in the database.
data reading and writing is independent of business logic, so this process lacks a middleware, which we use events to make up for. When a student chooses a course, it actually triggers a course selection event.
at this time, you need to abstract a course service to handle this event, such as judging the qualification of course selection and other business logic, and generate data objects to be passed to the data layer for addition, deletion and modification.
so here the student and course services are the domain layer, while the database operations belong to the basic services layer.
UI layer is inaccurate and should be the interface provided to the client. Generally speaking, it is the presentation layer, which can be rendered by the backend, such as jsp, or the data interface under the separation of the front and rear ends.
when the backend gets the data from the front end, it must first determine which domain objects should be handed over to handle the data. This layer is the application layer. The core of
ddd is that all the business logic of oo, can fall into the behavioral logic of domain objects, which makes it much easier to understand other concepts.