CN112860222A - Domain driver software design method based on micro-service - Google Patents
Domain driver software design method based on micro-service Download PDFInfo
- Publication number
- CN112860222A CN112860222A CN202110197550.7A CN202110197550A CN112860222A CN 112860222 A CN112860222 A CN 112860222A CN 202110197550 A CN202110197550 A CN 202110197550A CN 112860222 A CN112860222 A CN 112860222A
- Authority
- CN
- China
- Prior art keywords
- business
- layer
- field
- service
- model
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
Abstract
The invention provides a field driving software design method based on micro-service, which comprises the following steps: requirement investigation: in the process of requirement arrangement, combing a business model by combining business requirements; step two: dividing the field: the method comprises the following steps of (1) combing and dividing business fields according to business models, distinguishing each business field, and making detailed design drawings for the business models of the business fields one by one; step three: and (3) business modeling: creating a domain model of a domain layer according to the detailed design drawing, namely converting the business model into a business code, and simultaneously storing a domain model data object in a base layer; step four: and (3) testing a model: verifying the function of the domain model through unit testing; step five: and (3) system development: and finishing interface design, realizing development of an interface layer and an application layer according to interface requirements, and setting an expansion layer with function expansion according to business conditions.
Description
Technical Field
The invention relates to a field-driven software design method based on micro-services, and belongs to the technical field of software system design.
Background
The 21 st century informatization industry is developed vigorously, almost all informatization services are not separated from a software system, and with the deep development of the internet and the addition of a large number of terminal users, the informatization technology is also changed from a single machine service to a distributed service. Software is used as an information carrier, with the development of a distributed system, services become more and more complex, and how to design a set of system architecture capable of coping with continuous evolution and iteration becomes more and more urgent.
Most of the software design methods of the present day are designed based on a data-driven mode, namely, business analysis and processing are started from a data perspective. In a data-driven design approach, the service function is usually developed by using an interface as a guide. Namely: the service is driven by the function, and the service function is written from where the interface function is located, so that the service code logic is disordered, the service logic is easily disordered, and the maintenance and the expansion are not easy to realize. A large number of practices prove that the mode has serious defects, specifically:
service and product derailment: because the developer pays attention to the data processing process, the overall control of the business is ignored, and the details of the business are distributed in the data processing process, so that the business problem is easy to be derailed from the actually delivered product, and even if the business problem is controlled by more management means, the management means are difficult to control due to the fact that the standardization is not available.
The product of the stacking process is unstable: with the development of services, the demands for continuous adjustment require new functions to be added to the existing software systems. However, since the software service logic cannot be controlled and no complete expansion system is provided, the iterative software product cannot be stabilized. The butterfly effect is easily caused in each iterative upgrading process, and other functions are easily involved to cause a large number of accidents, so that the overall stability of the software product is influenced.
Functional adjustments involve a very large amount: in the development process oriented to data driving, not only the butterfly effect is easy to cause, but also the butterfly effect is easy to modify and involves the whole body. Because the logic of the service system is in the process of data processing, when the function logic is adjusted, other functions may be affected by the adjustment of certain function data, so that the functions and functions are affected with each other to change the position and move the whole body.
Disclosure of Invention
In order to solve the problems, the invention provides a field driving software design method based on micro-service, which has the following specific technical scheme,
a field driving software design method based on micro service comprises the following steps:
the method comprises the following steps: requirement investigation: in the process of requirement arrangement, combing a business model by combining business requirements;
step two: dividing the field: the method comprises the following steps of (1) combing and dividing business fields according to business models, distinguishing each business field, and making detailed design drawings for the business models of the business fields one by one;
step three: and (3) business modeling: creating a domain model of a domain layer according to the detailed design drawing, namely converting the business model into a business code, and simultaneously storing a domain model data object in a base layer;
step four: and (3) testing a model: verifying the function of the domain model through unit testing;
step five: and (3) system development: and finishing interface design, realizing development of an interface layer and an application layer according to interface requirements, and setting an expansion layer with function expansion according to business conditions.
Preferably, the interface layer depends on the application layer, the application layer depends on the base layer, and the base layer depends on the field layer, and the application layer realizes the dependence on the field layer through the base layer.
Preferably, the interface layer is an external open layer of the service, and is an open interface service for providing access calls to the client.
Preferably, the application layer is configured to provide function calls based on a business domain, so as to provide business support services for the function interfaces around the business domain.
Preferably, the domain layer is also called a service logic layer, and the domain layer performs service abstraction according to the service logic and converts the required service into a domain model.
Preferably, the expansion layer is a message expansion issued in the form of a message or an event for internal changes of the business logic.
Preferably, the data adaptation between the interface layer and the application layer is implemented by a service logic module, and the service logic module includes an application layer and a domain layer.
Preferably, the detailed design drawing is a visual UML class drawing.
The invention has the beneficial effects that:
(1) unified business model
The business model is visual (UML visual class diagram) and standardized (UML standard specification), and can enable clients, project managers and research and development personnel to quickly achieve the unity of business understanding through unifying the standardized business model, so that the business understanding deviation between the clients and the research and development is avoided, the influence of the personnel flow of a project group on the project is also avoided, and the business model can also be used as a system design document during the subsequent function iteration, and the quick reasonable judgment on the function adjustment is made.
(2) Simplifying business complexity
The simplification of business complexity and the building block service provide two means, one means is visual business logic modeling, and the other means is establishing a model by dividing the field. The complex business can be simplified through the division of the field, and the simple business logic can be visualized through the visualization of the unified business model, so that the business logic can be further polished and simplified.
(3) Improving service reusability
Because in the building block service, the domain model in the domain layer does not depend on any resource. Compared with the case that each domain model is a character model in 3D design, the models are not mutually involved, so that the multiplexing in other required scenes can be easily realized, and the reusability of software business logic is improved.
(4) Infrastructure capable of being replaced at will
Since the domain level does not rely on infrastructure (foundation level) in the building block service, this non-mandatory dependency is flexible enough to allow their replacement at will when needed. After different infrastructures are switched, only simple adaptation of the model and the data is needed, the service logic does not need to be changed, and the system can normally run.
(5) Easier unit testing
The unit test is a very key step in the development process, but under the development of data-oriented drive, because the layers are mutually dependent and the service model is not separated and dispersed in each layer, the unit test on the system function cannot be well carried out, and the test can be carried out only after the whole system is deployed. Under the building block service, because the domain model does not depend on any resource, the domain model can be easily subjected to full-coverage unit test and check to ensure the quality of the system and also ensure the iterative update of the system.
(6) Easier expansion and upgrade
The building block service is designed by taking 0CP theory as reference, and emphasizes that software needs open expansion and closed modification. Under the building block service, the expansion maintenance of the business system can be realized through an open interface and an expansion layer. And the building block service name can be very easily expanded and spliced with other business systems, and in a large business system, the building block service can be quickly expanded and spliced with each business system through accumulated building block service, so that the building of the large system is completed, and the building block service name comes from.
(7) Software sustainable iterative maintenance
Based on the method, means such as a unified service model, unit test, an expansion mechanism and the like can be provided, so that the stacking process of the software is more stable and continuous, and the sustainable and stable iterative development of a software system is promoted.
Drawings
FIG. 1 is a flow chart of a domain driver software design method based on microservice according to the present invention.
FIG. 2 is a block diagram of a building block service of the present invention.
FIG. 3 is a software architecture diagram of the building block service of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The software system developed based on the micro-service idea provides access to the outside in the form of software service. Each software service designed is expected to be as follows: the software design method has the advantages of clear business logic, clear system architecture level, easy maintenance of business codes, easy test and confirmation of functional logic, no mutual influence between services, mutual independence and smooth expansion of each service under the condition of not changing codes, and is designed for the purpose. The software service designed by the method can be very easily combined into a large-scale software system in a software assembly mode, and the software service designed by the method is called as follows: the building block service, the components of which are shown in fig. 2. Each building block service is composed of the five plates, which are respectively as follows: interface layer, application layer, field layer, basic layer, expansion layer.
As shown in fig. 1, a domain driver software design method based on micro-services includes the following steps:
the method comprises the following steps: requirement investigation: in the process of requirement arrangement, combing a business model by combining business requirements; the business model may be rough at this stage, but it is clear that the business logic flow relationship is clear and can be more easily agreed with the customer.
Step two: dividing the field: after the integral function requirement of the project is obtained, the business fields are sorted and divided according to the business models, each business field is distinguished, the business models of the business fields one by one are designed in detail, and the detailed design is a visual UML class diagram.
Step three: and (3) business modeling: after the division and the combing of the business fields are finished, a field model of a field layer is established according to the detailed design drawing, namely the business model is converted into a business code, and meanwhile, a field model data object is stored in the basic layer.
Step four: and (3) testing a model: after modeling is completed, the function of the field model is verified through unit testing, and meanwhile, the reasonability of the field model can be further checked and confirmed, so that reasonable compliance of the designed field model is ensured.
Step five: and (3) system development: and finishing interface design, realizing development of an interface layer and an application layer according to interface requirements, setting an expansion layer with function expansion according to business conditions, reserving and increasing event expansion information in advance, and preparing for future function expansion.
Step six: product release: the product can be released after the functional test and the performance test are completed. And the CI/CD can be integrated on the release link of the system to complete the unit test and check of the system, and the system is deployed after the detection is passed. Therefore, the follow-up function upgrading can be performed with the service logic confirmation check in advance, and the submitted function version is ensured to have no known function defects.
The interface layer depends on the application layer, the base layer depends on the field layer, the application layer does not depend on the field layer directly, but depends on the base layer to realize the dependence on the field layer, and the dependence is called dependence inversion in informatization. There are two main considerations as to why the design relies on inversion:
1. the multiplexing of the domain layer model is facilitated. Since the domain layer does not depend on anything, the migration multiplexing is easy.
2. Due to the independence of the domain layer, the full-coverage unit test can be easily carried out on the domain, and the completeness of the business model is ensured.
The interface layer provides an external access interface disclosed by the service, is an external open layer of the service, is an open interface service and is used for providing access and calling for the client.
The application layer is used for providing function calling based on the business field so as to provide business support service for the function interface around the business field.
The domain layer is also called a business logic layer, and when a software system is designed, the domain layer performs business abstraction according to business logic and converts required business into a domain model, namely the domain model indicated in the domain drive design.
The base layer, also referred to as a resource layer, has the primary responsibility of persisting the domain model, or restoring persisted data to the domain model.
The expansion layer is a message expansion issued in the form of messages, events and the like according to the internal change of the business logic.
As shown in fig. 3, the building block service has the following components from left to right: client (client); interface Layer; business Logic (Business module); expansion Layer; the Infrastructure Layer. The client is a calling party of the building block service, and the business module comprises an application layer and a field layer.
The Client comprises a presentation layer and a service call, the presentation layer does not limit the technical type, and the B/S, C/S architecture can call the service.
An Interface Layer is an open Layer for business, and is an open Interface service for providing access calls to clients.
Business Logic is used for data adaptation of the interface layer and the application layer, and mainly used for data adaptation and conversion of the interface.
Business Logic/Application Layer is an Application Layer in the field of DDD, and is mainly used for adaptation investigation of Business functions and models, or Business arrangement of models. The domain driven design is also referred to as DDD.
Business Logic/Domain Layer is a model Layer in the DDD Domain, is the core of Business Logic, and is also the main embodiment of visualization Business. The model may be subdivided into Entity, ValueObject, Service, Factory, etc. according to DDD.
The Infrastructure Layer is an Infrastructure Layer, and the unified operation on data is put in the Infrastructure Layer, and the Layer mainly has the function of converting the model and the data.
An Expansion Layer is mainly used for collecting Expansion Event messages of a business field model, and the Expansion Layer and an interface Layer belong to an Expansion mode of a system.
The building block service follows the principle of open and close (software entities are open for extension and closed for modification). The building block service takes business logic as a system core, maps business requirements through a model of a domain layer, and supports external expansion of system functions through internal interaction events of the domain model.
Although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that various changes in the embodiments and/or modifications of the invention can be made, and equivalents and modifications of some features of the invention can be made without departing from the spirit and scope of the invention.
Claims (8)
1. A field driving software design method based on micro service is characterized in that: the method comprises the following steps:
the method comprises the following steps: requirement investigation: in the process of requirement arrangement, combing a business model by combining business requirements;
step two: dividing the field: the method comprises the following steps of (1) combing and dividing business fields according to business models, distinguishing each business field, and making detailed design drawings for the business models of the business fields one by one;
step three: and (3) business modeling: creating a domain model of a domain layer according to the detailed design drawing, namely converting the business model into a business code, and simultaneously storing a domain model data object in a base layer;
step four: and (3) testing a model: verifying the function of the domain model through unit testing;
step five: and (3) system development: and finishing interface design, realizing development of an interface layer and an application layer according to interface requirements, and setting an expansion layer with function expansion according to business conditions.
2. The field-driven software design method based on microservice according to claim 1, characterized in that: the interface layer depends on the application layer, the application layer depends on the base layer, the base layer depends on the field layer, and the application layer realizes the dependence on the field layer through the base layer.
3. The field-driven software design method based on microservice according to claim 1, characterized in that: the interface layer is an externally open layer of the service, is an open interface service and is used for providing access and call for the client.
4. The field-driven software design method based on microservice according to claim 1, characterized in that: the application layer is used for providing function calling based on the business field so as to provide business support service for the function interface around the business field.
5. The field-driven software design method based on microservice according to claim 1, characterized in that: the domain layer is also called a business logic layer, and the domain layer makes business abstraction according to business logic and converts required business into a domain model.
6. The field-driven software design method based on microservice according to claim 1, characterized in that: the expansion layer is a message expansion issued in the form of messages and events aiming at the internal change of the business logic.
7. The field-driven software design method based on microservice according to claim 1, characterized in that: the data adaptation between the interface layer and the application layer is realized through a service logic module, and the service logic module comprises an application layer and a field layer.
8. The field-driven software design method based on microservice according to claim 1, characterized in that: the detailed design drawing is a visual UML class drawing.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110197550.7A CN112860222A (en) | 2021-02-22 | 2021-02-22 | Domain driver software design method based on micro-service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110197550.7A CN112860222A (en) | 2021-02-22 | 2021-02-22 | Domain driver software design method based on micro-service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112860222A true CN112860222A (en) | 2021-05-28 |
Family
ID=75988535
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110197550.7A Pending CN112860222A (en) | 2021-02-22 | 2021-02-22 | Domain driver software design method based on micro-service |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112860222A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116301760A (en) * | 2023-05-22 | 2023-06-23 | 深圳市长亮科技股份有限公司 | Application design system for software development |
| WO2023151239A1 (en) * | 2022-02-14 | 2023-08-17 | 华为云计算技术有限公司 | Micro-service creation method and related device |
| CN117270825A (en) * | 2023-10-25 | 2023-12-22 | 苏州工业职业技术学院 | Flexible software development method and suite for industrial complex business requirements |
-
2021
- 2021-02-22 CN CN202110197550.7A patent/CN112860222A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023151239A1 (en) * | 2022-02-14 | 2023-08-17 | 华为云计算技术有限公司 | Micro-service creation method and related device |
| CN116301760A (en) * | 2023-05-22 | 2023-06-23 | 深圳市长亮科技股份有限公司 | Application design system for software development |
| CN116301760B (en) * | 2023-05-22 | 2023-09-05 | 深圳市长亮科技股份有限公司 | Application Design System for Software Development |
| CN117270825A (en) * | 2023-10-25 | 2023-12-22 | 苏州工业职业技术学院 | Flexible software development method and suite for industrial complex business requirements |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112860222A (en) | Domain driver software design method based on micro-service | |
| US7188335B1 (en) | Product configuration using configuration patterns | |
| US20210271651A1 (en) | Compliance lifecycle management for cloud-based resources | |
| CN107479867A (en) | Application software plug-in unit operation method and device | |
| CN102750597B (en) | A kind of computer implemented method and apparatus for integrated heterogeneous journey | |
| US20070198562A1 (en) | Method and Apparatus for Ensuring Business Process Integration Capability for one or more Distributed Component Systems in Communication with one or more Legacy Systems | |
| US20240143909A1 (en) | System and Method for Electronic Document Interaction with External Resources | |
| CN115878112A (en) | Multi-party complex business agreement intelligent contract generating system and generating method thereof | |
| CN110825718B (en) | Information system data architecture model and construction method thereof | |
| CN105893591A (en) | Intelligent compiling technology of data sharing service | |
| US20080300943A1 (en) | Techniques for project transformation and management | |
| CN101339506B (en) | Device for implementing software products resource and version management | |
| CN109918361A (en) | The creation method and device and data-storage system of vehicle diagnosis database | |
| CN109981792A (en) | A kind of method and device for business processing based on cloud platform | |
| Ryu et al. | A framework for managing the evolution of business protocols in web services | |
| CN109783083A (en) | WEB application development approach and its system | |
| CN113515267A (en) | PaaS platform based on industrial Internet of things | |
| CN110969414A (en) | Cross-platform workflow implementation method and system based on Java | |
| CN114116900A (en) | Efficient trading system and development method based on MDD model | |
| KR100712685B1 (en) | Construction process information management system | |
| US20210173638A1 (en) | Design pattern recognition | |
| Schmid et al. | Qrygraph: A graphical tool for big data analytics | |
| CN106802805A (en) | A kind of application service management method and device for being applicable server admin | |
| Rana et al. | A generalised coordination design pattern for the ex-man component model | |
| CN113542323A (en) | Service processing method, device, equipment and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |