06 | field events: decoupling micro service key

  • background
    • During event storms, we find that in addition to the business of commands and operations, there is a very important event that often leads to further business operations, called a domain event in DDD.
  • define
    • Domain events are an important part of the domain model to represent events that occur in the domain, a domain event that leads to further business operations
    • Is a step in a business process, such as a specific action after some action is triggered
  • How are domain events identified
    • When analyzing user scenarios, we capture key words in the mouths of business, requirements people, and domain experts, such as “What happened… Then…” Etc.
  • Domain events within microservices
    • When domain events occur between aggregations within microservices, event entity construction and event data persistence are completed after domain events occur. Publisher aggregations publish events to the event bus, and subscribers receive event data to complete subsequent business operations
    • Personally, you can use Spring’s Event or Guava’s EventBus to do this
  • Domain events between microservices
    • Domain events across microservices enable business collaboration between different bounded contexts or domain models. The main purpose is to decouple microservices and reduce the pressure of real-time service access between microservices.
    • This is mq
    • The downside is that simultaneous data changes across microservices require the introduction of distributed transactions to ensure data consistency.
    • Distributed transactions can affect system performance and increase coupling between microservices, so we should avoid using distributed transactions as much as possible
  • Overall architecture design for domain events
    • Events include:
      • Build and publish events
      • Persistence of event data
      • Event bus
      • Message middleware
      • Event reception and processing

07 | DDD layered architecture: effectively reduce dependencies between layer and layer

background

  • There are several microservice architecture models, such as clean architecture, CQRS, and hexagonal architecture. Although each architecture pattern was proposed in different times and backgrounds, its core concept is to design a “high cohesion and low coupling” architecture to easily realize the evolution of architecture.
  • With the emergence of DDD layered architecture, architecture boundaries become more and more clear, and it plays a very important role in the microservices architecture model

What is DDD layering

  • User interface layer
    • The user interface layer is responsible for displaying information to users and interpreting user instructions
  • The application layer
    • The application layer is a thin layer that should theoretically have no business rules or logic and is oriented toward use cases and process-related operations
    • Application services are at the application layer and are responsible for composing, orchestrating and forwarding services, handling the execution sequence of business use cases and assembling results, and publishing them forward as coarse-grained services through API gateways.
    • Application services can also perform security authentication, permission verification, transaction control, send or subscribe to domain events, and so on.
  • Domain layer
    • The domain layer represents the business capabilities of the domain model and is used to express business concepts, business states, and business rules.
  • Base layer
    • The base layer runs through all layers and provides common technologies and basic services for other layers, including third-party tools, drivers, message-oriented middleware, gateways, files, caches, and databases. The more common feature is to provide database persistence.

How does DDD hierarchy drive architecture evolution? The hierarchy of objects in the domain model is, from the inside out, value objects, entities, aggregates, and bounded contexts. How does a three-tier architecture evolve to a DDD layered architecture, where entity methods are composed and encapsulated by domain services, and domain services are composed and encapsulated by applications?

08 | micro service architecture models: comparison and analysis of several common model

Clean Architecture (Onion Architecture)

  • The most important principle of clean architecture is the dependency principle, which defines the dependencies at each level, the lower the dependencies, the higher the code level, and the more core capabilities. The outer circle code depends on pointing only to the inner circle, and the inner circle doesn’t need to know anything about the outer circle.

Responsibilities:
  • The domain model implements the core business logic in the domain and encapsulates enterprise-level business rules
  • Domain service implementations involve complex business logic involving multiple entities
  • Application service realizes service composition and orchestration related to user operation. It contains application specific business process rules and encapsulates and realizes all use cases of the system
  • The outermost layer mainly provides adaptation capabilities, which can be divided into active adaptation and passive adaptation. Active adaptation Enables external users, web pages, batch processing, and automated tests to adapt internal service logic.
  • Passive adaptation mainly ADAPTS core business logic to access basic resources, such as database, cache, file system, and message middleware.
  • The domain model, domain service and application service in the red circle together form the software core business capability.

Hexagonal architecture (port adapter architecture)

The core idea of the hexagonal architecture is that applications interact with the outside world through ports

The functions are divided as follows:
  • The hexagon in the red circle realizes the core business logic of the application;
  • The outer hexagon provides interaction and access to external applications, drivers, and basic resources
  • API active adaptation is used to provide services for front-end applications, and resource access is realized by dependency inversion passive adaptation for basic resources.
The three architectural models focus on desktop and microservice design
  • define
    • The middle stage is essentially a subdomain of the domain, which may be a core domain, a general domain or a support domain. It is generally believed that Ali zhongtai corresponds to DDD’s common domain, and the common public capacity is deposited into Zhongtai to provide common shared services externally.
  • The construction of Taiwan should focus on the field model
    • The center needs to consider the sharing and reuse of capabilities at the height of the whole enterprise.
  • Microserver must have a reasonable architectural layer
    • The design of microservices should have the design idea of layers, so that each layer plays its own role and establishes the relationship between layers with loose coupling.
  • Decoupling and adaptation of applications and resources