Field-driven design book notes

Many factors make the software complex. The most important factor is the complexity of the field. domain-driven communication focuses on Domain Models as the core of communication between domain experts, analysts, and developers. therefore, we need to find a good domain model in development. A good domain model should not only stay on the surface, but go deep into the substantive structure of the domain. It is necessary to reach the level of understanding or proficient in the field of business. Of course, with the help of field experts, you can save some time and effort to mine domain business knowledge.

The domain model is a tool used by domain experts and analysts to accumulate knowledge from each other. It helps analysts understand domain knowledge and provides a standard expression for domain experts to describe domain knowledge in a rational manner, analyze and solve domain problems. In addition, the domain model is also a way for the development team to accumulate knowledge, helping developers understand the specific fields they are engaged in and improve modeling skills. The domain model is actually a common language for communication between domain experts and analysts and developers.

The essence of domain-driven design is "to digest a large amount of knowledge, and finally generate a model that reflects deep-level domain knowledge and focuses on key concepts ". the core idea of this book is to use a model as the basis for implementation, design, and team communication.

See http://kb.cnblogs.com/a/814784/

Domain-driven design book Structure

1. Let the domain model play a role: put forward the basic goal of domain-driven development

2. model-driven design constructor: extract the best practices of the modeling core into a set of basic constructor blocks.

3. Deep understanding through reconstruction: In-depth study of models-Implementation of initial design-repeated design-Reconstruction

4. Strategic Design: discusses complex systems, large organizations, interaction with external systems and legacy systems, and three principles applied to systems: context, refinement, and large-scale structure.

Part1: Let the domain model play a role

Developers must have obtained business knowledge in specialized fields, must practice modeling skills, and be proficient in field design.

CP1 digest knowledge

Elements of effective modeling: binding models and implementations, obtaining model-based languages, developing models with rich knowledge, refining models, brainstorming, and experimentation

Digest knowledge and continuous learning (efficient teams need to consciously accumulate knowledge and continue learning ).

Learn domain knowledge in a variety of ways: communicate with domain experts to find and learn relevant materials/knowledge... So that we can build a deep model.

Communication and communication in CP2

Ubiquitous language: unified terminology and team language. using a unified Vocabulary (Class Name and main operations), all developers describe system artifacts, tasks, and functions in a model-based language.

Use the model as the language center to ensure that the team is engaged in all communication activities andCodeAnd stick to this language.

Documents should be supplemented by code and verbal communication and must be kept up-to-date.

CP3 binding model and implementation

MDD (model-driven design): To analyze a model, you must grasp the basic concepts in the field and describe it in a way that is easy to understand and express. each part of the software should be designed to faithfully reflect the model.Software development is a constantly refined model, a unified iteration process of design and code. The consistency between design and model must be maintained within a controllable range...

The design requires repeated research fields and continuous reconstruction to extract important concepts into simple and clear models.

MDD uses the model to solve the problem. The project team extracts the model by digesting knowledge. MDD closely integrates the model and design. ubiquitous language becomes a channel for developers to transfer information between field experts and software products.

Part2: construction block of model-driven design

The design style mentioned in this book mainly follows the principle of "Responsibility-driven design.

This figure is an MDD navigation chart used to describe the patterns and associations in this section.

Cp4 separation Field

Separate domain objects from other functions in the system to avoid confusion between domain concepts and concepts related to other software technologies.

1 layered architecture hierarchy

UI Layer

Application Layer (coordinates tasks and assigns work for the Domain Layer)

Domain Layer (responsible for business concepts, reflecting the status of business conditions, composed of business logic and implementation)

Infrastructure layer (providing general technology for the upper layer)

The intermediate layer (Domain Layer) and the second side (application layer, UI Layer and infrastructure layer). The model belongs to the domain layer.

2The SMART-UI "anti-pattern"

Implement business logic in the user interface layer and embed business rules --- anti-Pattern

Models represented in cp5 Software

Three Modes of the model: entity, value object, and service

Is an object indicating a food with continuity and identifier used to describe a certain state attribute of a thing? This is the difference between entity and value object.

There are also some expressions for operations and actions-service.

In MDD, module is a part of the model and should reflect related concepts in the field.

How to Reduce Association

1. Define a traversal direction
2. Add a qualifier to effectively reduce multiple associations
3. Eliminate unnecessary associations

Mode:

1. Entity (reference object): the basic responsibility of entity is to ensure continuity so that its behavior is clearer and predictable. Keep the entity concise.
2. Value Object: it is used to describe a certain aspect of the domain, and the object without a conceptual identifier is called value object. It should be classified as value object only when it is concerned with the attributes of the model.
3. Service: The operation in the model, which is not suitable for modeling as an object-"Service
4. Module: low coupling among modules. The module is not only a division of code, but a division of concepts. A collection of cohesion concepts.

All designs are based on models.

Cp6 domain object Lifecycle

Objects Created are either deleted or archived.

Mode: Aggregate-> Factory/Repository

Aggregate modeling is used to control the relationship and demarcation between objects, create objects using factory, and query and retrieve persistent objects using repository.

In aggregate mode, only external entities can be accessed. The attributes in aggregate cannot be referenced by external entities.

Mode: Factory

Provides unified interfaces for creating complex objects (factory methods, abstract factories, and creators in the design mode are suitable. If you need to create them based on different rules, you may need to create them using the Policy mode ), fixed rules can be defined directly within the factory.

Mode: Repository

Object Storage persistence operations basically involve database operations. Of course, you can use different forms such as files and streams to persist the model.

CP7 language: an extension example

The second part is used for demonstration.

Better understanding of Part3 through refactoring

Continuous refactoring adds flexibility to the areas that need to be modified in the system, on the premise that you must continuously master domain knowledge.

Cp8 breakthrough

The team can master, accumulate, digest knowledge, and continuously reconstruct it.The reconstruction principle always takes a small step and ensures the normal operation of the system. Deep modeling (in-depth domain knowledge and calm decision-making ).

Cp9 transforms implicit concepts into explicit concepts

Concept mining:Listen to the language of experts in the field, explore different concepts, do not understand, do not communicate well, check for deficiencies, think about contradictions, read books, and try.

How to model a non-explicit concept: Display constraints (Rules)

Mode: Specification

Use specification to encapsulate rules.

Encapsulate attributes through features: bowl-> caliber, material, price, and other attributes through model abstraction encapsulation...

Cp10: flexible design

To make changes easier and clearer, the fundamental goal is to improve cohesion and reduce coupling.

Mode: Intention revealing-interfaces (interpreted Interface)-class, function, and other element names show their purpose and value of the customer's developers. expose interfaces rather than implementations (name indicates intention)

Mode: side efect free function (no side-effects function)-Focus on function functions to avoid side-effects functions and encapsulate complex computing into side efect free function, marginal effects/side effects are caused by State recording and changes, such as deep copy (which is often used in Orm such as Hibernate) to avoid side effect.

Mode: assertion-prediction result, exposing function side effects

Mode: Conceptual contour (concept outline)-place a specific type of content in the corresponding region to make the local area relatively stable.

Mode: Standalone class-encapsulates complex computing into standalone class.

Mode: Closure of operation-the return value is of the same type as the operation object. It is mainly used for value objects and is used to define operations that do not involve other concepts, usually value objects.

Declarative design: refersProgramOr write part of the program into an executable specification (specification), e. g .... Logical operators encapsulate andoperation, oroperation... Use a very accurate description.

Cp11: Application of Analysis Mode

Analysis Mode: a set of concepts used to represent common structures in business modeling. the main role of the analysis model is to draw on the experience of other projects and combine the experiences of extensive design discussions and implementation results in those projects with the current model.

This chapter describes the application of the Analysis Mode in modeling.

Cp12: Apply design patterns to models

Not all design patterns apply to domain patterns. This chapter uses composite/strategy to demonstrate the design patterns to solve domain problems.

Mode: Strategy-Define a groupAlgorithm, Encapsulate each algorithm and enable them to replace each other. strategy allows the algorithm to change independently of the customers who use it.

Startegy can be used to model business policies during Domain Modeling.

Mode Composite-Organize the object into a tree structure to represent part-the overall hierarchy. With composite, you can perform the same processing on individual objects and object combinations.

Nested containers... Display their composition transparently.

Cp13: Get a deeper understanding through refactoring

To get a deeper understanding of the three things that need to be done through reconstruction, take the field as the basis, view things in a different way, and always insist on talking with experts in the field.

The reason for restructuring: the model is inconsistent with that of experts in the field. New requirements cannot be added to the Model naturally.

Continuous reconstruction: a deeper understanding through reconstruction is a continuous process.

Part4 Strategic Design

The principle of strategic design: reduces the dependency between different parts and improves clarity without losing key interoperability and collaboration.

The strategic design principle must focus on capturing the concept core of the system-the "vision" of the system ".

This chapter focuses on context, refinement, and large scale structure.

Clarify the relationship between models through context, reduce confusion through refinement, focus attention on the right place, and describe the overall system through a large proportion of structure.

Cp14: maintain model integrity

Use bounded context to define the application scope of each model. Context map gives the project context and the overall view between them.

Mode: bounded context-clearly defines the context and strictly maintains the consistency of the model in the boundary.

Mode: continous integration-merge all the work in the context frequently enough to make them consistent. There are two main operations: Integration of model concepts and integration of implementation.

Mode: context map-describes the contact points between models, clarifies the transformations required for each communication, and highlights any shared content. define the respective regions of the context and map the Interaction Using Context map. in the Oracle ADF architecture, binding is used for context conversion-Inter-module coupling. http://www.west263.com/info/html/chengxusheji/Javajishu/20080225/45537.html

Relationship between bounded Context

Mode: Shared kernel-core domain, shared domain among teams

Mode: customer/supplier (customer/supplier relationship)-Relationship between upstream and downstream teams

Mode: confirmist (followers)-strictly abide by the model of the upstream team

Mode: antiduplicate uption layer-create an isolated layer and provide related functions to customers based on their own domain model. Facade/adapter + Converter

Mode: Separater way-strict requirements for reverse queries. If the relationship between the two groups of functions is not necessary, then this can be completely independent.

Mode: Open host service-defines a protocol and uses your subsystem as a set of services for access by other systems. Web Service, SOA

Mode: published language-use the publicly available language as the communication medium for interaction. xml

14.12: provides guidance and instructions on application of various models in projects.

CP15 Refining

The model is refined by knowledge, but the motivation for refinement is to extract the most valuable part, which distinguishes our software from other software (core domain)

Mode: core domain-core domain

Mode: Generic subdomain-universal domain

Mode: domain Vision Statement (domain prospect description)

Mode: highlighited core (highlighted core)

Mode: cohesive mechanism (Cohesion Mechanism)-separated to a single Lightweight Framework. Pay attention to the formula algorithm.

Mode: segregated core (isolated domain)

 

Mode: Abstract Core (Abstract kernel)

Focus on core domain, improve core isolation, and extract supporting sub-fields into general fields

CP16: Large Scale Structure

Mode: Evolving order

Model: System metaphor (system metaphor)

Mode: Responsibility layer: Job, responsibility

Potential layer, job layer, decision support layer, policy layer, and commitment Layer

Mode: A group of knowledge level objects that describe the behaviors of another group of objects.

Mode: pluggable component framework (plug-in component framework)

Cp17: Comprehensive Application