Shulou(Shulou.com)06/03 Report--

This book is a dictionary reference book written by Eric Evans for his own "Domain-driven Design-the way to deal with Software Core complexity". It can be used to quickly find many concepts in "Domain-driven Design" and their concise explanations.

Addresses for other articles in this series:

Domain Driven Design Reference (1)-- Preface

Domain Driven Design Reference (2)-- make the model work

Domain Driven Design Reference (3)-- the Construction Module of Model-driven Design

Domain Driven Design Reference (4)-- flexible Design

Ⅲ. Flexible design

For a project to accelerate development, rather than being dragged down by its own historical baggage, you need a design that works well with it, and it will make a difference. A flexible design.

Flexible design is a supplement to depth modeling.

Developers play two roles, each of which must be accomplished through design. The same person may play these two roles and can even switch back and forth in a few minutes, but this is not the case with the code. One role is the client-side developer who uses design to weave domain objects into application code or other domain layer code. Flexible design reveals a deep potential model and makes its potential clear. Client developers have the flexibility to use a set of concepts of minimal loose coupling to represent a series of scenarios in the domain. Design elements are fused together in a natural way, and the results are predictable, clear features, and robust.

Equally important, the design must be subject to the developer to change it. To make changes, the design must be easy to understand and express the same underlying model that client developers are using. It must follow the concept of a deep model in the domain, so most of the changes will be flexible in terms of flexibility. The impact of its code must be transparent, so the consequences of the changes will be easy to predict.

Make the behavior characteristic obvious.

Reduce the cost of change

Create software developers to work with

Interpretive interface

If the developer must consider the implementation of the component in order to use it, the value of encapsulation is lost. If someone other than the original developer must infer the purpose of the object or operation based on its implementation, the new developer may infer the intention that the operation or class is executed only by accident. If this is not intended, then the code may be valid for the time being, but the conceptual basis of the design has been broken and the two developers will work for cross-purposes.

Therefore:

Name the class name and operation name to describe their effect and purpose, without referring to their methods of compliance. This reduces the need for customer developers to understand internally. These names should conform to the common language so that team members can quickly infer their meaning. Write a test for the behavior before creating it to force your mind into client developer mode.

No side effect method

The interaction of multiple rules or combinations of calculations becomes very difficult to predict. To invoke an operation, the developer must understand its implementation and the implementation of all delegates in order to predict the result. If the developer is forced to pierce the mask layer, the use of any abstract interface is limited. Without safe and predictable abstractions, developers must limit composition explosions and set lower limits on viable rich behaviors.

Therefore:

Put as much program logic as possible into the function and return the result with no obvious side effects. Strictly separate commands (methods that cause significant state changes) into very simple operations that do not return domain information. When a concept of responsibility is found, the side effects are further controlled by converting complex logic into value objects.

All operations on the value object should be functions with no side effects.

Assertion

When the side effects of an operation are implicitly defined only through implementation, the design of a large number of delegates becomes a chaotic causal relationship. The only way to understand the program is to track execution through the branch path. The value of encapsulation is lost. The need to track concrete execution causes abstraction to fail.

Therefore:

The post-conditions of state operations and the invariance of classes and aggregates. If assertions cannot be written directly in your programming language, write automatic unit tests for them. Write them into documents or diagrams that conform to the style of the project development process.

Look for models with a set of related concepts that guide developers to infer expected assertions, speed up the learning curve, and reduce the risk of conflicting code.

Assertions define contracts for services and entity modifiers.

Assertions define invariance in aggregation.

Isolated class

Even in the same module, as dependencies increase, it becomes much more difficult to interpret the design. This adds to the burden of understanding and limits the design complexity that developers can handle. The implicit concept promotes this burden even more than the displayed reference.

Low coupling is the foundation of object-oriented design. Keep doing this if you can. Eliminate all other concepts in the diagram. Then the class will be completely independent and can be studied and understood separately. Each of these self-contained classes significantly reduces the burden of understanding a module.

Closing operation

Most interesting objects end up doing things that cannot be represented by basic elements.

Therefore:

Where appropriate, make it return the same type as its parameter when defining the operation. If the state of the implementer is used in the calculation, then the implementer is actually a parameter of the operation, so the parameter and return value should be of the same type as the implementer. This operation is a closure operation in a collection of instances of that type. The closure operation provides a high-level interface without introducing dependencies on other concepts.

This pattern is usually applied to the operation of value objects. Because the life cycle of an entity is important in the domain, you cannot create a new entity to answer a question. There are also operations that are closed under the entity type. You can request a property object from its subject object and retrieve another property. But generally speaking, the entity is not the kind of concept that is suitable to be the result of calculation. So, in most cases, this is an opportunity to find value objects.

You sometimes fall into half of this pattern. The parameter matches the implementer, but the return type is different, or the return type matches the recipient, and the parameter is different. These operations are not closed, but they give some imaginative space to think about the advantages of closure.

Declarative design

There can be no real guarantee in the program software. Named only in a way that evades assertions, the code may have additional side effects that are not excluded. No matter how model-oriented our design is, we still end up writing programs to produce conceptual interactions. And we spend most of our time writing boilerplate code that doesn't actually add any meaning or behavior. The interpretive interfaces and other patterns in this chapter are helpful, but they are unlikely to provide formal rigor to traditional object-oriented.

These are the motivations behind declarative design. The term means a lot to many people, but it usually indicates a way of writing a program or part of a program as an executable specification. A very precise description of attributes actually controls the software. In its various forms, it can be done by reflection mechanism or by code generation at compile time (traditional code is automatically generated based on declarations). This approach allows other developers to accept claims at face value. This is an absolute guarantee.

If developers bypass them intentionally or unintentionally, many declarative methods can be broken. This is likely to happen when the system is difficult to use or has too many restrictions. Everyone must follow the rules of the framework to reap the benefits of declarative programming.

A declarative design style

Once your design has an interpretive interface, no side-effect functions and assertions, you will enter the declarative field. Many of the benefits of declarative design are gained when you have composable elements that can communicate their meaning, and have characteristic or obvious effects, or no observable effects at all.

Flexible design makes it possible for client code to use a declarative design style. To illustrate this, the next section will introduce some of the patterns in this chapter to make the specification more flexible and declarative.

Formalism in the picture (formal painting)

Creating a strict conceptual framework from scratch is something you can't do every day. Sometimes during the life cycle of a project, you will find and improve one of them. But you can often use and adjust conceptual systems that have been established in your field or other areas for a long time, some of which have been refined and refined for centuries. For example, many business applications involve accounting. Accounting defines a set of perfect entities and rules that can easily adapt to deep models and flexible designs.

There are many such formal conceptual frameworks, but my personal favorite is math. It's amazing how useful it is to make some changes to the basic algorithm. Many fields include mathematics. Looking for it. Dig it up. Professional mathematics is clean, can be combined with clear rules, and people find it easy to understand.

Chapter 8 of this book discusses a real-world example, "Shares Math", domain-driven design.

Conceptual outline

Sometimes people cut off some functions for the sake of flexible combinations. Sometimes they encapsulate it in a complicated way. Sometimes they seek consistent granularity to bring all categories and operations to a similar level. These are too simplistic to be as effective as the general rules. But they are inspired by basic questions.

When the elements of a model or design are embedded in an overall structure, their functions are copied. The external interface does not represent everything the client might care about. Their meaning is difficult to understand because different concepts are mixed together.

On the contrary, decomposing classes and methods can unconsciously complicate the client, forcing client objects to know how to put small pieces together. To make matters worse, a concept may be completely lost. Half of the uranium atom is not uranium. Of course, it's not the size of the granularity that matters, but it's just the source of the granularity.

Therefore:

Break down design elements (operations, interfaces, classes, and aggregations) into cohesive units, taking into account your intuition about important branches of the domain. Observe the change and stability of the core through continuous reconstruction, and find the basic conceptual outline to explain these segmentation methods. Compare the consistency between the model and the domain, first of all, make it a feasible field of knowledge.

Flexible design based on depth model produces a set of simple interfaces that can be logically declared in a common language without the interference and maintenance burden of irrelevant options.

Author: Zachary_Fan

Source: http://www.cnblogs.com/Zachary-Fan/p/DDDReference4.html

If you want to get the message of your own article in time, you are welcome to scan the QR code below.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.