ABP framework actual combat series (2) – domain layer introduction

EF Core stands for Entity Framework Core. You can use EF Core to develop.net Core applications. EF Core can also be developed in Visual StudioVisual Studio for Mac or Visual Studio Code.

If you are not familiar with EF Core, you can read this article to get started on EF Core.

The EF Core is singled out in the ABP template not because there is anything special about the EF Core here, but because the EF Core here is responsible for domain objects.

The ABP framework architecture introduction mentioned that ABP is more than just an architecture, it also provides a best practice domain-driven Design (DDD) based architecture model.

As shown in the figure below, ABP has a domain layer between the application layer and the persistence layer.

Domain Level Overview

Domain-driven Design (DDD) : DDD is originally defined as a software development solution that starts with a unified language and ends with a layered architecture centered around business model objects through binding contexts. Following the principles of DDD, the common development steps are: understanding requirements, translating requirements into specifications, actual coding, and testing. DDD is designed to address the core complex lines of the business domain. However, using DDD requires a precise understanding of the business domain. Properly using DDD makes software development and implementation much easier

The structure of the domain layer is roughly as follows

The interior of the domain layer

  • The domain model

    • The module

    • The value object

      The DDD domain model contains both entities and value objects. A value object is defined entirely by its properties. The properties of a value object do not change after the instance is created. If both changes are made, the value object becomes an instance of another value object

    • Physical Entity Class

      Entities All objects derived from the entity class have properties, but not all objects can be fully identified by their set of properties. These objects are entities. In other words, if an object needs an ID feature to uniquely track it in context throughout its life cycle, the object has an identity and is treated as an entity. Value objects are simply aggregated data, and entities are usually composed of data and behavior. Behavior is the key to treating domain logic differently from application logic. The domain logic is in the domain layer, and the implementation of the use cases is in the application

      
public class Person : Entity
{
    public virtual string Name { get; set; }

    public virtual DateTime CreationTime { get; set; }

    public Person(a)
    { CreationTime = DateTime.Now; }}Copy the code

      The staff class is defined as an entity. It has two properties. In addition, the entity class defines the ID attribute. It is the primary key of the entity. Therefore, all entities have the same primary key name, which is ID.

      The type of id (primary key) can be changed. This is int (Int32) by default. If you want to define another type as id, you should explicitly declare it as follows:

    
  public class Person : Entity<long>
  {
      public virtual string Name { get; set; }

      public virtual DateTime CreationTime { get; set; }

      public Person(a)
      { CreationTime = DateTime.Now; }}Copy the code

    • Entity persistence

      The domain model must be persistent, but it does not care about persistence. The implementation of the domain model does not involve loading and saving operations. But persistence is an essential part of an application. At this point, the warehouse takes care of the work. Repositories are typically used outside of domain models, such as application layers and domain services. However, the contract for warehousing is at the domain level, and its implementation is at the infrastructure level.

  • The aggregation

When developers build domain models for binding contexts based on the use cases in the requirements, you will find that some individual entities always refer to each other. Logically related objects treated individually rather than collectively and as a whole can easily result in data blob code. You can then group and isolate the entities in the model through aggregation. It is common practice to decompose domain models into aggregations and then identify domain entities within the aggregations.

  • advantages

    • Business logic becomes simpler
    • Prevent tightly coupled models

  • Relationship between

    The root class of the aggregation hides the related classes from the caller and requires the caller to reference them in any interaction. In other words, an entity is only allowed to reference the same aggregated entity or the root of another entity. When an aggregation needs to refer to multiple entities that are not codescendants of another aggregation, that aggregation should refer to the root entity of another aggregation.

  • create

    The aggregate root object is the root of the group of objects that make up the aggregate. The aggregation root is visible throughout the domain model and can be directly referenced. Entities in an aggregation can have their identity and life cycle, but they cannot be referenced directly from before the aggregation. The aggregation root also has corresponding responsibilities:

    • The aggregation root ensures that objects within the aggregation are always in a valid state according to the application’s iyewu rules
    • The aggregation root is responsible for persisting all encapsulated objects
    • The aggregate root is responsible for cascading updates and deleting entities in the aggregate
    • The query operation can only get the aggregate root.

  • Field service

    The domain logic implemented by the methods of the domain service class is not part of a specific aggregation and may span multiple entities. Domain services coordinate aggregation and warehousing activities to enable business operations. At some point, domain services may use infrastructure services, such as sending E-mail or SMS

    • As a service contract
    • Transconvergent behavior
    • warehousing

  • Field events

    Domain events are used to fire an event when some domain event occurs. This avoids putting all the processing code in one place.

    • A developer can dynamically define a set of processors without touching the code that generates the event
    • The same event can be triggered in multiple places

GitHub address of the blogger

github.com/yuyue5945