I. Introduction to DDD layered architecture

This article examines Equinox open source projects under the CQRS architecture. The project has a 2.4K star on Github. I decided to analyze the Equinox project to learn about the CQRS architecture. When talking about CQRS architecture, we will briefly describe the DDD style first. In THE DDD layered architecture, it generally includes the presentation layer, application layer (application service layer), domain layer (domain service layer) and infrastructure layer. When the term service is used in DDD, such as domain service, application layer service, etc., the service refers to business logic, not to any technology such as WCF, Web service.

The following diagram shows the evolution from a classic three-tier architecture to a tiered architecture under DDD:

1. The presentation layer

2. Application service layer

The domain layer and infrastructure layer can be referenced in the application services layer and are services that orchestrate business use cases on top of the domain layer. This layer knows nothing about business rules and does not contain any business-relevant state information. Key features of this layer:

(1) This layer is for different front ends. This layer is related to and serves the presentation layer. Different presentation layers (mobile, WebAPI, Web) each have their own application services layer. This layer and the presentation layer belong to the front end of the system.

(2) The application services layer can be stateful, at least in terms of UI task progress.

(3) It takes the input model from the presentation layer and returns the viewmodel.

3. The domain layer

4. Infrastructure layer

This layer uses anything related to the specific technology: the data access persistence layer for THE O/RM tools, the implementation of the IOC container (Unity), and the implementation of many other crosscutting concerns such as security (Oauth2), logging, tracing, caching, and so on. The most prominent component is the persistence layer.

2. CQRS overview

1. Introduction

CQRS is a simplified improvement of the domain model architecture under the DDD development style. Any business system is basically query and write. Corresponding CQRS refers to the separation of command/query responsibilities. Query does not modify the system state in any way, but only returns data. Commands (writes), on the other hand, modify the state of the system, but return no data except a status code or acknowledgement. In CQRS, the query stack is based solely on SQL queries and can have no model, application layer or domain layer at all. The CQRS scheme can also prepare different databases (read and write) for the command stack and the query stack.

2. The benefits of CQRS

3.CQRS realizes global graph

In the global diagram, the right figure represents a double layered architecture with dotted lines separating the command channel from the query channel, with each channel having its own architecture. In the command channel, any request from the presentation layer becomes a command and is queued to the processor. Each command carries information. Each command is a logical unit that fully validates the state of the relevant objects, intelligently deciding which updates to perform and which to reject. A processing command may generate events (events are usually logging what happened to the command) that are handled by other registered components.

Overview of Equinox open Source projects

1. Prepare the environment

(1) Github open source address download. Full ASP.NET Core 2.2 Application with DDD, CQRS and Event Sourcing

Generatedatabase.sql; generateDatabase.sql;

(3) Modify the database connection address for ConnectionStrings in AppSettings. json.

2. Hierarchical description of the project

Application Domain: Equinox.domain, Equinox.domain.Core Infrastructure layer: Cross-cutting concerns under the Equinox.Infra.Data(EF Persistence) infrastructure layer: Equinox. Infra. CrossCutting. Bus (events) and command Bus Equinox. Infra. CrossCutting. Identity (such as login, registration, user management, authorization) Equinox. Infra. CrossCutting. The IoC (service injection of inversion of control)Copy the code

3. Project architecture process diagram

Flow chart correction: Domain layer Equinox. Domain does not need to refer to infrastructure layer event Bus Equinox. Infra. CrossCutting. Bus. In the DDD style, the domain layer is independent and in principle independent of other layers.

Iv. Performance level analysis

// ASP.NET Authorization Polices
 services.AddSingleton<IAuthorizationHandler, ClaimsRequirementHandler>();
Copy the code

5. Application service layer analysis

The Equinox.Application Application services layer includes configuration management for AutoMapper, which enables entity transfer between the view model and domain model. Defines the ICustomerAppService service interface to be invoked by the presentation layer and implemented by the CustomerAppService class. The project contains the viewmodel that Customer needs. There’s also the EventSource, the EventSource.

The CustomerAppService class implements the query, command, and event source of the presentation layer. The project structure is as follows:

6. Domain-level Domain.Core analysis

  // Inject the service
    services.AddMediatR(typeof(Startup));
Copy the code

/// <summary>
    ///The Message the Message
    ///Put in generic attributes, even generic tags, no attributes
    /// </summary>
    public abstract class Message : IRequest<bool>
    {
        /// <summary>
        ///Message type: The type of command or event that implements Message
        /// </summary>
        public string MessageType { get; protected set; }

        /// <summary>
        ///The aggregation ID
        /// </summary>
        public Guid AggregateId { get; protected set; }

        protected Message(){ MessageType = GetType().Name; }}Copy the code

/// <summary>
    ///Event Domain messages
    ///The event class is immutable; it represents what has happened, meaning there are only private sets and no write methods.
    ///Events store common attributes, such as when the event was triggered, by whom it was triggered, and the data version number.
    /// </summary>
    public abstract class Event : Message.INotification
    {
        public DateTime Timestamp { get; private set; }

        protected Event()
        {
            // Event timeTimestamp = DateTime.Now; }}Copy the code

/// <summary>
    ///Command Field Command that returns no result (void) but changes the state of the data object.
    /// </summary>
    public abstract class Command : Message
    {
        public DateTime Timestamp { get; private set; }

        //DTO binding verification, using Fluent API to implement
        public ValidationResult ValidationResult { get; set; }

        protected Command()
        {
            // Command time
            Timestamp = DateTime.Now;
        }

        // Implement DTO data validation for the Command abstract class
        public abstract bool IsValid();
    }
Copy the code

 public abstract class Entity
    　　public abstract class ValueObject<T> where T : ValueObject<T>
Copy the code

[HttpPost]
        [Authorize(Policy = "CanWriteCustomerData")]
        [Route("customer-management/edit-customer/{id:guid}")]
        [ValidateAntiForgeryToken]
        public IActionResult Edit(CustomerViewModel customerViewModel)
        {
            if(! ModelState.IsValid)return View(customerViewModel);

            _customerAppService.Update(customerViewModel);

            if (IsValidOperation())
                ViewBag.Sucesso = "Customer Updated!";

            return View(customerViewModel);
        }
Copy the code

Domain level Domain analysis

The following is the Domain project structure:

In the above structure, the Commands and Events folders are used to store data transfer objects for Commands and Events, respectively, which are anaemic DTO classes that can also be understood as domain entities. For example, the Commands data transfer object definition in the Commands folder:

/// <summary>
    ///The Customer data is passed to the object abstract class, and the Customer is put through the property
    /// </summary>
    public abstract class CustomerCommand : Command
    {
        public Guid Id { get; protected set; }

        public string Name { get; protected set; }

        public string Email { get; protected set; }

        public DateTime BirthDate { get; protected set; }}Copy the code

/// <summary>
    ///Customer Registers the command message parameter
    /// </summary>
    public class RegisterNewCustomerCommand : CustomerCommand
    {
        public RegisterNewCustomerCommand(string name, string email, DateTime birthDate)
        {
            Name = name;
            Email = email;
            BirthDate = birthDate;
        }

           /// <summary>
        ///Verify command information parameters
        /// </summary>
        /// <returns></returns>
        public override bool IsValid()
        {
            ValidationResult = new RegisterNewCustomerCommandValidation().Validate(this);
            returnValidationResult.IsValid; }}Copy the code

When a command is sent at the application services layer (bus. SendCommand), the command is handled by a class under the CommandHandlers folder at the domain layer, and the EF persistence layer is called to change the entity state. The following describes the execution process of the following commands. Starting from the presentation layer, a new customer is added as follows:

When you click Create in the presentation layer, call the application Services layer Register method and trigger a new event with the following code:

/// <summary>
        ///new
        /// </summary>
        /// <param name="customerViewModel">The view model</param>
        public void Register(CustomerViewModel customerViewModel)
        {
            / / the view model is mapped to the entity RegisterNewCustomerCommand new orders
            var registerCommand = _mapper.Map<RegisterNewCustomerCommand>(customerViewModel);
            Bus.SendCommand(registerCommand);
        }
Copy the code

After SendCommand sends the command, Handle in the Domain-level CustomerCommandHandler class handles the command as follows:

/// <summary>
        ///Customer Registration command processing
        /// </summary>
        /// <param name="message"></param>
        /// <param name="cancellationToken"></param>
        /// <returns></returns>
        public Task<bool> Handle(RegisterNewCustomerCommand message, CancellationToken cancellationToken)
        {
            // Validate entity attributes
            if(! message.IsValid()) { NotifyValidationErrors(message);return Task.FromResult(false);
            }

            // Turn command messages into domain entities
            var customer = new Customer(Guid.NewGuid(), message.Name, message.Email, message.BirthDate);

            // Initiate an event if the registered user mail already exists
            if(_customerRepository.GetByEmail(customer.Email) ! =null)
            {
                Bus.RaiseEvent(new DomainNotification(message.MessageType, "The customer e-mail has already been taken."));
                return Task.FromResult(false);
            }

            / / by the Equinox. Infra. Data. The Repository for Data persistence. An event is something that happened in the system in the past. This event is usually the result of a command.
            _customerRepository.Add(customer);

            // After the new command is added successfully, use the event to record the command.
            if (Commit())
            {
                Bus.RaiseEvent(new CustomerRegisteredEvent(customer.Id, customer.Name, customer.Email, customer.BirthDate));
            }

            return Task.FromResult(true);
        }
Copy the code

The following is the information about the registered customer and the event data generated by the registration, as shown below:

In the domain layer Interfaces folder, one of the most important including IRepository interface, is through the Equinox. Infra. Data. The Repository to implement the interface, for Data persistence. The following is the domain level warehouse interface:

/// <summary>
    ///Domain - level warehouse interfaces define common methods
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IRepository<TEntity> : IDisposable where TEntity : class
    {
        void Add(TEntity obj);
        TEntity GetById(Guid id);
        IQueryable<TEntity> GetAll();
        void Update(TEntity obj);
        void Remove(Guid id);
        int SaveChanges();
    }
Copy the code

/// <summary>
    ///Customer warehousing interface, extended over base warehousing
    /// </summary>
    public interface ICustomerRepository : IRepository<Customer>
    {
        Customer GetByEmail(string email);
    }
Copy the code

Interfaces folder also defines IUser and IUnitOfWork interface classes, and it takes Equinox. Infra. Data. The Repository.

Viii. Infrastructure layer analysis

 public bool Commit()
        {
            return _context.SaveChanges() > 0;
        }
Copy the code

  public virtual void Add(TEntity obj)
        {
            DbSet.Add(obj);
        }
Copy the code

Command bus analysis

Equinox. Infra. CrossCutting. Used in the middleware MediatR Bus project, The InMemoryBus class is defined to implement domain-level IMediatorHandler command bus interface sending, using SendCommand (T) and RaiseEvent (T) methods to send commands and events.

MediatR is a decoupling for message sending and message processing. MediatR is an in-process messaging mechanism. Supports synchronous or asynchronous request/response, command, query, notification, and event messaging, and supports intelligent scheduling of messages via C# generics. IRequest and INotification correspond to unicast and multicast message abstractions respectively.

For example, in the domain layer, Message implements IRequest as follows:

/// <summary>
    ///The Message the Message
    ///Put in generic attributes, even generic tags, no attributes. IRequest<T>- Has a return value
    /// </summary>
    public abstract class Message : IRequest<bool>
Copy the code

The Equinox. Infra. CrossCutting. Identity mainly for user management, authorization, migration management. Equinox. Infra. CrossCutting. The IoC service is needed to do the projects in the overall solution injection.