1. Introduction

The most **** near by a old brother ridicule: you send this article of the bottom logic is what? Where is the top-level design? What is the ultimate delivered value? Where is the grip of the process? How to ensure a closed loop of results? Where do you stand out from others? What’s the advantage? Where are your thoughts and precipitation? Have you developed your own methodology? Have you researched similar warehouses? Have you done a performance test? Did you write the single test? Is the documentation clear? After small white saw does not ask a question to be able to learn? Do you repeat the wheel? What are your strengths? Why do you need this advantage? How can you prove your superiority? How can you ensure the quality of your framework? – Strong taste of the Internet, haha!

Previously, in small factories, the business scenario and organizational structure are very small, the production relationship and link are relatively simple, and the business complexity is relatively small. But in the so-called (life force), a consortium of business scenarios and more to support the rapid expansion of the business, organization structure, upstream and downstream of the production relations and link the giant complex, so the research and development in the very great degree is to solve the problem of the complexity of the business, as a “big mud pie” project, can give a business project/team/technical architecture will bring extremely high complexity, At the same time, it also brings a variety of problems, which make a new business faced with the business or service to take over suddenly confused (congratulations, you have succeeded in the pit!) “So getting a new hire up and running quickly and productive requires a strong set of coaching tools and methodologies.

In the face of such business difficulties, we can extend chairman MAO’s words: “despise the enemy strategically, but attach importance to the enemy tactically.”

  • Strategy: the overall and long-term program planning of using resources to achieve goals;
  • Tactics: the use of resources to achieve the goal of local short-term planning and implementation methods;
  • The difference between strategy and tactics is the difference between whole game and local game, long game and short game, abstract game and concrete game.

A senior veteran must have both good strategic planning and tactical execution skills, which means that he must be able to see the distance and be down-to-earth. For this ability, DDD becomes a required course.

2.DDD definition and function

2.1 define

Domain-driven design (DDD) is a software design method that provides strategic and tactical modeling tools. The strategic part is used to understand and sort out the business, find the core business, and better divide the domain/system/service. The tactical part is to land on the code, use the code to clearly represent the business, and have a mature guidance on how to layer the code and how to design it.

  • Strategic design: Strategic design tools help teams make the most competitive software design choices and business integration decisions and maximize the benefits of these core competitive software models. A context-bound strategic design pattern is used to separate domain models and develop a common language for domain models, such as domain terminology.
  • Tactical design: Tactical implementation tools help teams design practical software that accurately models how businesses operate. Grouping together several entities and value objects of the appropriate size is also known as the aggregation pattern of.

2.2 role

DDD can help improve the effectiveness of design and achieve high value software. It can also be used to solve the complexity/extension/development cost of software design and continuously deliver the most effective software design and implementation in today’s increasingly competitive market environment. Possible changes to DDD adoption:

  • Improve the success rate of projects;
  • Enhance business competitiveness and correctly model business requirements;
  • The software architecture can be relatively easily iteratively evolved and extended.

3. Limit the context

Bounded context is a semantic and contextual boundary, which means that each component of the software model within the boundary has specific meaning and processes specific transactions. These components in bounded context have specific context and semantic motivation. It can be understood that the bounded context is a problem space and the solution space for that problem.

  • Problem space: The place where advanced strategic analysis and design steps are performed within the constraints of a given project. Simple charts can be used to show the high-level project drivers in the discussion and document key goals and risks.
  • Solution space: The place where solutions are actually implemented, identified in the problem space discussion as the core domain, which is called the core domain when the limiting context is developed as a key strategic initiative for the organization. The solution in the bounded context is implemented primarily through source code and test code, but code is also written in the solution space to support integration with other bounded contexts.
  • Common language: The team develops a language to express the software model within its boundaries in the bounded context, which is used by each member of the development software model in the bounded context. The language is the language used in software model team communication, and software model of the source code is written expression of the language, it is strongly recommended that the term definition domain, such as an English word represents a specific model and write the word remark, for different regions, different team members can accurately understand the meaning of special language, The language can be used in databases, system designs, design documents, and more.

Core domain identification is a continuous refining process, put a pile of mixed together component separation, in some way to extract the most important content, the form will be the core domain more value, and can make the product research and development of resources more focus to the minimum viable product, get user feedback, and on the minimum viable product continued rapid iteration, To get a stable core product. A team should work in a bounded context, each bounded context should have an independent source code for the warehouse, a team could work in multiple limit context, but teams should not work in the same limit context, and separate the common language should be used in the same way, the different bounded context of source code and isolated from the database schema, Also, store the acceptance tests, unit tests, and primary source code in the same bounded context.

4. Architecture

Not only is there a domain model in the bounded context, but there is also a reasonable framework to organize the domain model and output the related domain capabilities. Common in bounded contexts: input adapters, such as user interface controllers, REST end nodes, and message listeners; Application services that orchestrate use cases and manage transactions; Output adapters, such as persistence management and message sender.

Several architectural styles are commonly seen today:

  • Event-driven architecture: an event-driven architecture is used as a medium to realize the decoupling between the caller and the interface implementer. Event-driven architecture is that the caller and the called do not know each other, and they are only coupled to the intermediate message queue.

  • Separation of command and query responsibilities (CQRS): Separate read and write operations into separate models, using commands to update data and queries to read data, but never modifying the data. Commands should be task-based, not data-centric. Commands can be placed on a queue for asynchronous processing rather than synchronous processing.

  • Responsive architecture and Actor Model: An event-driven implementation that is particularly good at handling scenarios where multiple clients concurrently request services from a server. The Reactor mode, for example, decouples concurrently requested services and distributes them to corresponding event handlers for processing. At present, many popular open source frameworks have used the Reactor model, such as netty, NIO, and an actor model such as Akka.

  • Service-oriented Architecture (SOA) : Service-oriented Architecture (SOA) is a component model that links different functional units of an application through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner and should be independent of the hardware platform, operating system, and programming language that implements the service. This allows services built in a variety of such systems to interact in a unified and common way. The most common one today is the RPC architecture, which includes three major components: service registry, service provider, and service consumer.

  • Representational State Transfer (REST): Describes an architecture-style interconnected system. REST constraints, when applied as a whole, result in a simple, scalable, efficient, secure, and reliable architecture. Due to its simplicity, lightweight, and the ability to transfer data directly over HTTP. A multi-tier architecture for Web services and dynamic Web applications enables a clear separation of reusability, simplicity, extensibility, and component responsiveness.

5. Child domain

There are always many bounded contexts in DDD projects, one of which is bound to be the core domain, and many different subdomains exist in the other bounded contexts. Subdomains is part of the whole business areas, the implementation of the subdomains on behalf of a single, logical model, most areas of the business, too large and complex as hard as a whole to analyze, so we only care about those who must be involved in a single project subdomains, child domain can be used to logically split the entire business, to create subdomains by DDD, It will be implemented with a clear bounded context.

There are three types of subdomains in a project:

  • Core domain: It is a unique, well-defined domain model within the organization that requires significant strategic investment and significant resources to build a common language in a well-defined context, the most important project in the organization, and the core competency of the business.
  • Support subdomains: This type of scenario calls for “custom development” to support the core domain as much as possible, but the investment in it is by no means the same as the core domain, and may consider using an outsourcing approach to define the bound context.
  • Generic subdomains: A generic subdomain can be outsourced, sourced, or provided by an internal team, but will not be allocated the same R&D resources as the core domain.

Some of the system boundaries in the business domain may be legacy systems, perhaps built by your team, or acquired through the purchase of software licenses, in which case the subdomain is the current focus. The whole legacy system may be filled with multiple intricate models, and each subdomain and its boundary can be accurately identified. Thinking and discussing such systems with subdomains helps us to deal with the display of intricate models. When using such tools, we can identify those subdomains that are valuable to the business and more important to the project, and reduce the other subdomains to a secondary position. When using DDD, bound contexts should correspond one-to-one to subdomains (1:1), and if there is a bound context, the goal is to categorize a corresponding subdomain model.

6. Context mapping

6.1 Type of context mapping

Partnerships exist between two or more teams, each responsible for a bounded context. Two teams are united by an interdependent set of goals, often facing synchronous schedules and interrelated work, and using continuous integration pairs to keep integration efforts in alignment. Maintaining long-term relationships can be challenging, so many teams entering into partnerships may do their best to set an expiration date for the relationship and maintain it only when each other’s strengths are in play.

  • Shared kernel: Two teams share a small but common model. The teams must agree on the shared model elements, and it is possible that only one of them will maintain, build, and test the code for the shared model.
  • Customer-supplier: The supplier is upstream, the customer is downstream, and it is the supplier that dominates this relationship because it must provide what the customer needs. The customer needs to work with the supplier to develop a plan to meet this expectation, but ultimately the supplier decides what the customer gets and when.
  • Follower: The relationship exists between the upstream team and the downstream team. The upstream team has no incentive to meet the specific needs of the downstream team. For various reasons, the downstream team cannot invest the resources to translate the generic language of the upstream model to suit their specific needs, so they can only adapt to the upstream model. The anticorrosion layer is one of the most useful tools for the downstream team. It is the most defensive context mapping. The downstream team creates a translation layer between its generic model and the generic language (model) located upstream of it, separating the downstream model from the upstream model and translating between the two.
  • Open host service: Defines a set of protocols or interfaces that allow the bounded context to be accessed as a set of services. The protocol is open and available to all clients that need to integrate with the bounded context. The service is provided through an API and has detailed documentation.
  • Published language: a well-documented information exchange language that can be easily used and translated across many consumer bound contexts. Consumers who need to read and write information can translate the shared language into their own. The best example is the SDK.

6.2 Context Mapping Integration mode

  • Soap-based RPC: The current mainstream Dubbo/HSF framework is a typical example. The design idea of SOAP-based RPC is to make the invocation of another system’s service as simple as the invocation of the same local procedure or method. The SOAP request needs to be transmitted through the network to reach the relevant system, and the result will be returned after successful execution. But this integration approach lacks robustness, which is why there is a lot of fault-tolerant design in the RPC framework;
  • RESTful HTTP: Focuses on the resources exchanged between contexts, such as POST, GET, PUT, and DELETE. A server that supports REST interfaces should provide open host services and documentation. In the same way, it is also difficult to trace and log the whole link due to network or service provider failure, network delay, etc. Design errors using REST directly expose aggregation in the model,
  • Message mechanism: When using message mechanism for integration, a lot of work by the client bounded context subscription by itself or another field event issued by the bounded context, using the message mechanism can eliminate the blocking calls, an area where messages can be one or more subscribers consumption, commonly used message middleware can be used in the peak/decoupling, But also may cause the field event too much, consumption is too slow and so on.

7. Aggregation design in subdomains

There is still a need for detailed design (at the tactical level) for specific subdomains. There are modeling tools such as entity, value object, aggregation, and aggregation root in the subdomain. Aggregation design ideas or tools are used to design. An aggregation is composed of one or more entities, and an entity becomes the aggregation root.

  • Entity: an entity model is an independent, each entity model has a unique identifier, it can be individuals and all other types of the same or different entities, and each entity has a life cycle, the main factors of entity is separated from other modeling tools is the uniqueness of it;

  • Value object: A value object is a model of an immutable conceptual whole. In this model, instead of unique identifiers, equality is determined by comparing attributes encapsulated by the type. A value object is not a thing, but is often used to describe, quantify, or measure an entity;

  • Aggregate root: Each aggregate root entity controls all other aggregated elements. The name of the root entity is the conceptual name of the aggregate root. Each aggregate forms the boundary that guarantees transactional consistency. This means that in a single aggregation, where control is committed to the database transaction, all of its components are consistent according to business rules. An aggregation also establishes a conceptually complete model of transaction consistency.

  • Transactions: how to isolate changes to aggregation, and how to ensure that business invariance (that is, principles that software must adhere to) is consistent across every business operation. Whether through atomic database transactions or other methods of controlling requirements, the state of aggregation, or the form it manifests through event traceability methods, must be safely and correctly transferred and maintained;

A general principle of aggregation design: Only one aggregation instance can be modified and committed in one transaction. A rule of thumb for aggregation:

  • Protecting business rule invariance within the aggregation boundaries;
  • The polymerization should be designed to be small;
  • References to other aggregations can only be made by identifier;
  • Update other aggregations with final conformance;

8. Manage DDD in Agile projects

DDD not only plays a role in software design and development, but also in agile project management. In order to better enhance the business and product value, DDD can be added to several nodes in the version development cycle to continuously improve the business value in the product version iteration cycle.

8.1 SWOT Analysis

Swot analysis method is to further analyze the strengths and weaknesses of the project/product as well as the opportunities and threats of the enterprise’s external environment according to the resources of the project/product, and then select the appropriate strategy. SWOT analysis is a method to comprehensively consider various factors of internal and external conditions and make a systematic evaluation, so as to select the best business strategy. In the iteration cycle of each version, at the time point of requirement analysis/planning/review, SWOT analysis tool can make the development direction of business or product more focused, and put r&d resources in the real direction.

  • 1. A business or project characteristic that leads one over another;
  • 3. Characteristics of a business or project that lag behind a competitor;
  • Opportunity: elements that can leverage the strengths of a project;
  • Threat: A factor that exists in the environment and can cause problems for the business or project.

8.2 Task identification and workload estimation

Task identification and workload estimation is an important step in doing agile iterations. Time represents manpower and money, and the accuracy of estimation directly determines the release time bias. In the usual agile iteration, the evaluation is based on user stories, with coarse granularity and slightly inaccurate estimation. In this case, domain-driven design concepts such as domain event/command/aggregation + simplicity and complexity are used as estimation metrics to make them more accurate and realistic.

9. To summarize

This is a “review summary” of my journey from 0 to 1, where I want to use DDD to sort out and refactor the complex business. This paper mainly introduces some concepts, tools and means used in the design of DDD strategy and tactics, the definition and function of DDD, the definition of bound context and the types and integration modes between contexts, and the concepts of aggregation, entity, value object, aggregation root and transaction in the subdomain. Actual practice has proved that DDD is very effective in solving the complexity of software systems and can Hold the business quickly.

reference

Blog.csdn.net/yasinshaw/a…

Hiddenpps.blog.csdn.net/article/det… Describe the three CQRS architecture patterns

Baike.baidu.com/item/%E9%9D… Service-oriented architectural patterns

Cloud.tencent.com/developer/a… What is event-driven architecture?

—————————————————————————————–

If you think this article is well written, give me a thumbs up!

Please like 👍 follow ❤️ share 👥