CN114048641A - Design method and device of model in power marketing field - Google Patents

Abstract

The application discloses a design method and a device of a power marketing field model, wherein a business object is abstracted from an obtained business model, the field object is determined based on the business object, a root of aggregation, an entity, a value object, a field service and a field event are identified from the field object, aggregation is determined based on the root of aggregation, the entity and the value object, the field model is established through the root of aggregation, the entity, the value object, the aggregation, the field service and the field event and is automatically verified, the verified field model is converted into a data model, a data code is generated through the data model, and software development operation is executed. Based on the scheme, the field object identification method guides a model designer to carry out field object design work, so that the field model development has a concrete implementation methodology basis, and the operation difficulty of the field model is reduced. And the field model is automatically checked, the error rate of checking the field model is reduced, and the accurate positioning of the error position of the field model is realized.

Description

Design method and device of model in power marketing field

Technical Field

The application relates to the technical field of power marketing, in particular to a method and a device for designing a model in the field of power marketing.

Background

A domain model is an abstraction of a problem domain, which is a visual representation of objects in the real world or domain. A domain model, also called a problem domain model, represents real or abstract concepts of a domain.

The domain model reflects the essence of user service requirements in the domain; the domain model only reflects services, is irrelevant to any technical implementation, and not only can reflect some entity concepts in the domain, such as clients, electric energy meters, meter reading records, addresses and the like, but also can reflect some process concepts in the domain, such as account transfer and the like.

The existing field model lacks a system theoretical basis, the field model design is mainly developed by depending on experience, and the systematicness and the theories are lacked. The domain model has no specific implementation method, the operation difficulty is high, and the multi-person cooperative work is difficult. Because the domain model is large in scale, a large amount of manpower, material resources and financial resources are required to be invested for manually verifying the domain model, and the error rate of manually verifying the domain model is high, so that the error position of the domain model cannot be accurately positioned.

Therefore, the existing operation domain model has high difficulty and the error rate of the verification of the domain model is high.

Disclosure of Invention

The application discloses a design method and device of a power marketing field model, and aims to reduce the operation difficulty of the field model. And the field model is automatically checked, the error rate of checking the field model is reduced, and the accurate positioning of the error position of the field model is realized.

In order to achieve the purpose, the technical scheme is as follows:

the first aspect of the application discloses a design method of a model in the field of power marketing, which comprises the following steps:

acquiring a service demand, and creating a service model according to the service demand;

abstracting a business object from the business model; the business object is used for representing a business core object with preset key attributes;

determining a domain object based on the business object, and identifying an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service and a domain event from the domain object;

determining an aggregation based on the aggregation root, the entity, and the value object;

building a domain model from the aggregation root, the entity, the value object, the aggregation, the domain service, and the domain event;

automatically checking the domain model; the automatic verification is used for improving the precision of the domain model;

converting the verified domain model into a data model, and generating a data code through the data model;

and executing software development operation through the data codes.

Preferably, the abstracting the business object from the business model includes:

performing domain division according to the service requirements to obtain a plurality of sub-domains;

identifying the service requirements and the service model to obtain a service use case and a system use case;

in the plurality of sub-domains, dividing a bound context by the business use case and the system use case; the bounding context is a boundary on semantics and context; the boundary is used for ensuring the consistency of the domain model;

abstracting a business object from the business model based on the bound context.

Preferably, the method further comprises the following steps:

a core subdomain, a common subdomain, and a support subdomain are identified from the subdomains.

Preferably, the determining a domain object based on the business object and identifying an aggregation root, an entity, a value object, a domain service and a domain event from the domain object includes:

abstracting the business object into a domain object by an abstraction method;

identifying, from the domain objects, an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event through a business scenario.

Preferably, the automatically verifying the domain model includes:

verifying the domain model through a domain model verifier and a preset rule; the domain model locator is used for locating the error position of the domain model; the preset rules are used for ensuring the correctness, consistency and logicality of the domain model.

The second aspect of the present application discloses a model design device in the field of electric power marketing, the device includes:

the system comprises an acquisition unit, a service model creating unit and a service model creating unit, wherein the acquisition unit is used for acquiring service requirements and creating a service model according to the service requirements;

the abstraction unit is used for abstracting a business object from the business model; the business object is used for representing a business core object with preset key attributes;

a first determining unit, configured to determine a domain object based on the business object, and identify an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event from the domain object;

a second determining unit to determine an aggregation based on the aggregation root, the entity, and the value object;

a building unit to build a domain model through the aggregation root, the entity, the value object, the aggregation, the domain service, and the domain event; the domain model is a visual model of an object in a business range;

the verification unit is used for automatically verifying the domain model; the automatic verification is used for improving the precision of the domain model;

the conversion unit is used for converting the verified domain model into a data model and generating a data code through the data model;

and the execution unit is used for executing software development operation through the data codes.

Preferably, the abstraction unit includes:

the first division module is used for carrying out field division according to the service requirements to obtain a plurality of sub-fields;

the first identification module is used for identifying the service requirements and the service model to obtain a service use case and a system use case;

a second partitioning module, configured to partition a bound context from the service use case and the system use case in the plurality of sub-domains; the bounding context is a boundary on semantics and context; the boundary is used for ensuring the consistency of the domain model;

a first abstraction module to abstract a business object from the business model based on the bound context.

Preferably, the method further comprises the following steps:

an identification unit for identifying a core sub-domain, a general sub-domain and a support sub-domain from the sub-domains.

Preferably, the determining unit includes:

the second abstraction module is used for abstracting the business object into a domain object by an abstraction method;

and the second identification module is used for identifying an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service and a domain event from the domain objects through a business scene.

Preferably, the verification unit is specifically configured to:

verifying the domain model through a domain model verifier and a preset rule; the domain model locator is used for locating the error position of the domain model; the preset rules are used for ensuring the correctness, consistency and logicality of the domain model.

According to the technical scheme, the service requirement is obtained, the service model is created according to the service requirement, the service object is abstracted from the service model and used for representing the service core object with preset key attributes, the domain object is determined based on the service object, the aggregation root, the entity associated with the aggregation root, the value object associated with the aggregation root, the domain service and the domain event are identified from the domain object, the aggregation is determined based on the aggregation root, the entity and the value object, the domain model is constructed through the aggregation root, the entity, the value object, the aggregation, the domain service and the domain event, the domain model is automatically checked and used for improving the precision of the domain model, the checked domain model is converted into the data model, the data code is generated through the data model, and software development operation is executed through the data code. Based on the scheme, the field object identification method guides a model designer to carry out field object design work, so that the field model development has a concrete implementation methodology basis, and the operation difficulty of the field model is reduced. And the field model is automatically checked, the error rate of checking the field model is reduced, and the accurate positioning of the error position of the field model is realized.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

Fig. 1 is a schematic flow chart of a method for designing a model in the field of electric power marketing disclosed in an embodiment of the present application;

FIG. 2 is a schematic diagram of a domain model converted into a data model according to an embodiment of the present disclosure;

FIG. 3 is a schematic illustration of determining aggregation as disclosed in an embodiment of the present application;

FIG. 4 is a schematic diagram of an automated verification of a domain model disclosed in an embodiment of the present application;

fig. 5 is a schematic structural diagram of a device for designing a model in the field of electric power marketing disclosed in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, 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 application.

In this application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

As known from the background art, the existing field model lacks a system theoretical basis, the field model design is developed mainly by depending on experience, and the systematicness and the theories are lacked. The domain model has no specific implementation method, the operation difficulty is high, and the multi-person cooperative work is difficult. Because the domain model is large in scale, a large amount of manpower, material resources and financial resources are required to be invested for manually verifying the domain model, and the error rate of manually verifying the domain model is high, so that the error position of the domain model cannot be accurately positioned.

In order to solve the problems, the embodiment of the application discloses a design method and a device of a model in the field of electric power marketing, and a model designer is guided to carry out field object design work by a field object identification method, so that the development of the field model has a concrete implementation methodology basis, and the operation difficulty of the field model is reduced. And the field model is automatically checked, the error rate of checking the field model is reduced, and the accurate positioning of the error position of the field model is realized. The specific implementation is illustrated by the following examples.

Referring to fig. 1, a schematic flow chart of a method for designing a model in a power marketing field disclosed in an embodiment of the present application is shown, where the method for designing a model in a power marketing field mainly includes the following steps:

s101: and acquiring the service requirement, and creating a service model according to the service requirement.

In S101, service requirement analysis and design are carried out according to customer requirements, and service requirements are obtained.

The business model includes objects, elements, attributes, behaviors, etc. that are involved in the business requirements.

The object is an abstraction of objective things and comprises attributes and behaviors, wherein the attributes are information needing to be memorized, and the behaviors are services capable of being provided by the object.

And establishing a business model according to business requirements, and using the business model to improve business processes, domain modeling and the like.

S102: abstracting a business object from the business model; the business object is used for representing the business core object with preset key attributes.

Business Objects (BO) are components that retrieve and process data. Is a simple real-world software abstraction. Business objects are typically located in a middle or business logic layer.

The process of abstracting a business object from a business model is shown as A1-A4:

a1: and performing domain division according to the service requirements to obtain a plurality of subdomains.

Where a domain refers to a business context, i.e., what an organization does and everything it contains. Each organization has its scope and manner of doing things. The scope of the service and the activities performed therein are the domains.

The fields comprise a client domain, a management domain, a product domain, a market domain, a sales domain, a service domain, an interaction domain, an operation domain, an ecological cooperation domain, a delivery domain, a measurement domain, a charging domain, a client Internet of things domain and the like.

A subdomain is a split of one large problem domain into many smaller problem domains. In daily development, a large software system is usually split into several subsystems. This partitioning may be based on architectural considerations as well as infrastructure considerations. In Domain Drive Design (DDD), the partitioning of business systems is Domain-based, i.e., business-based.

The business system refers to business links required by enterprises for positioning, roles played by all partners, and modes and contents of cooperation and transaction of interest relatives.

Software development is not a matter of one-kick, software development cannot be carried out on the premise of not knowing a product (or an industry field), a large amount of business knowledge is usually required to be combed before software development, and then the software development is carried out when the software development reaches the level of software design. In the process of business knowledge combing, certain domain knowledge is formed inevitably, and software design is driven step by step according to the domain knowledge, which is the basic concept of domain-driven design. The core of the domain-driven design is to establish a correct domain-driven model.

For convenience of understanding, the process of dividing the domain by the service requirement to obtain a plurality of sub-domains is illustrated here by way of example:

for example, taking a peach tree as an example, a complete biological knowledge system is established for the peach tree, and the process is as follows:

the first step is as follows: the subject of the study, i.e. the field of study, is determined, where the subject of the study is a peach tree.

The second step is that: the study object is subdivided, the peach tree is subdivided into organs, and the organs are divided into two types, namely a nutrition organ and a reproduction organ. Wherein the vegetative organs include roots, stems and leaves, and the reproductive organs include flowers, fruits and seeds. The knowledge system of the peach tree is the domain of problems we have identified to study, corresponding to the domain of DDD. Organs such as roots, stems, leaves, flowers, fruits and seeds are the sub-divided problem domains. This process is the process by which the DDD subdivides a domain into multiple subdomains.

The third step: the organ is subdivided and the organ is subdivided into tissues. For example, the leaf organs can be subdivided into protective, vegetative, and conducting tissues. This process is the process by which the DDD further subdivides the subdomain into a plurality of subdomains. After the sub-domains are divided, the process can be returned to verify whether the sub-domains divided at present solve the problem of all problem spaces. If not, then appropriate adjustments may be made.

The fourth step: the tissue is subdivided into cells, which become the smallest unit of our research. The cell walls between the cells define the boundaries of the cells and also the minimum boundary to be studied. The cell is formed by substances such as cell nucleus, mitochondria, cell membrane and the like, and the substances cooperate together to ensure that the cell has the specific biological function of the cell. Cells are understood herein as the polymerization of DDD. The aggregation root (aggregate root) is divided into a clear boundary, objects outside the aggregation root cannot directly access objects inside the aggregation root, if the internal objects need to be accessed, the aggregation root must be accessed first, and then the aggregation internal objects are navigated to), substances such as cell nucleus, mitochondria and cell membrane inside the cell can be understood as aggregation root, entities, value objects and the like inside the aggregation, and the entities cooperate together to complete specific business functions in the aggregation.

A2: and identifying the service requirements and the service model to obtain a service use case and a system use case.

Wherein the service use case is used to capture the functional requirements. Such as a profile manager, whose business goal is to maintain profiles. For example, the forum administrator has service targets of maintenance users, maintenance posts, etc., i.e., the service use case embodies the requirements (maintenance users, maintenance posts, etc.).

And the need can be fulfilled in many ways. How to implement it is embodied by the system use case. For example, a business object of maintaining a file may have a variety of different use case scenarios to accomplish it, where the scenarios include how to add a file, how to modify a file, how to delete a file, and so on.

The business use case and the system use case are planned by standing at a business view and a system construction view of a client respectively. The business use cases are complete direct requirements, the system use cases are not detailed division of business logic, but implementation modes of the system on the requirements are not independent of programming, and the system functional requirements to be built are formed by the system use cases. Both business use cases and system use cases are requirement categories that represent business scope and system scope, respectively.

A3: in a plurality of sub-domains, a bound context is divided by a service use case and a system use case; a bounding context is a boundary on semantics and context; the boundaries are used to ensure consistency of the domain model.

Wherein, the general language is abstracted by the service requirement, the noun terms are formed, and the common cognition of the service personnel and the technical personnel in the boundary context is realized.

If we consider the service scope as a space, it has both "problem space" and "solution space". The problem space is from a business requirements perspective, while the solution space is from an implementation software perspective. The two are slightly different, and finally, the problem space is divided by using a subdomain and the solution space is divided by using a limit context.

A bounding context is a boundary on both semantics and context, meaning that each component within the boundary that represents the software model has a specific meaning and processes a specific transaction. The components in the bound context have specific context and semantic data; the bounding context defines the application scope of each model, and the consistency of the domain model is ensured in each bounding context. In different bounding contexts, the domain model may not guarantee consistency.

The boundary context is separated according to different attention points, the respective boundary is determined according to the strength of the coupling relation, and the boundary is needed to be defined the more the boundary is at the weakest place of the relation. And classifying the activities according to the service correlation, the coupling strength and the separated focus points, and finding out the boundaries existing between different classes, which is the meaning of the bound context. The context is a business target, and the limit is a boundary for protecting and isolating the context, so that confusion and concept inconsistency caused by the fact that the business target is not single are avoided.

Three principles of bounding context partitioning:

(1) the concepts are the same and the meanings are different. If a model is ambiguous within a context, where the ambiguity is located, they should be broken down into different bounding contexts.

(2) And (4) an external system. Sometimes, the business system needs to make a cross with the external system, and at this time, the part making a cross with the external system can be split out to realize better expansibility. Once the external system changes, the core business logic is not affected.

(3) And (5) tissue expansion. The two teams are not required to be developed together in a limited context as far as possible, and the problems of unsmooth communication, difficult integration and the like can exist.

To facilitate understanding of the bound context, this is illustrated here by way of example:

example 1 the sentence "i want to be quiet" is generally intended to convey the meaning of "i want to be quiet". But someone will understand who is "quiet," and it is important to see the contextual context.

Example 2, also Apple, expressed in fruit stores and Apple cellphone monographs, are completely different. The role of a bound context is to define the scope of application of the model. In the same context, it is guaranteed that the model is logically uniform, regardless of whether it is applicable outside the boundaries.

Optionally, a core subdomain, a generic subdomain, and a supporting subdomain are identified from the subdomains.

Wherein the core sub-domain is a unique, well-defined domain model to which strategic investment is made and which invests a large amount of resources in a well-defined context to carefully polish the common language. The core subdomain is the most important item in the organization, which is the difference from other competitors, and is the core competitiveness of the successful business.

Solutions for generic sub-domains can be purchased off-the-shelf, can be outsourced, or can be implemented by an internal team, but do not allocate the same high-quality development resources as the core domain. The generic sub-domain is used by the entire service system.

Modeling scenarios such as the support subdomain advocate "custom development" because no ready solution is found. It is invested to the same extent in the core domain anyway. It is also contemplated to implement such bounding contexts using outsourcing to avoid large investments by mistakenly considering them as strategic. Supporting the subdomain from being used by the entire system, the necessary ability to complete the business.

A4: the business objects are abstracted from the business model based on the bound context.

Wherein the cooperation between the bound contexts is realized by bound context mapping.

S103: a domain object is determined based on the business object, and an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event are identified from the domain object.

Domain objects (also called entity classes) represent the state of a business, and are persisted through the presentation, business, and persistence tiers, and ultimately to a database.

The aggregation root is mainly used for avoiding the problem of data inconsistency between aggregation and entities due to the lack of uniform business rule control of a complex data model.

When the individual characteristics of one object need to be considered or different objects need to be distinguished, the concept of the entity field is introduced. An entity is a unique thing and can change continuously over a considerable period of time. Multiple modifications may be made to an entity, and an entity object may differ significantly from its previous state. However, they are still an entity since they have the same identity (identity).

Value objects are used to describe objects that have no conceptual identification of an aspect of the domain itself, and value objects are instantiated to provide values or design elements only and we are concerned with what these design elements are and not who they are. The book refers to colors and numbers as common value objects. Such an object is stateless, does not generate behavior itself, and does not have life cycle evolution.

Specifically, the process of determining the domain object based on the business object and identifying the aggregation root, the entity, the value object, the domain service and the domain event from the domain object is as follows:

firstly, a business object is abstracted into a domain object through an abstraction method.

On the basis of the business object, the domain object is formed through methods such as inheritance, abstraction, splitting and the like.

Then, through the business scenario, an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event are identified from the domain objects.

The service scene comprises customer electricity utilization consultation, electric vehicle charging and battery replacement, meter warehousing and export, meter verification, newly-added electricity utilization application and the like.

S104: an aggregation is determined based on the aggregation root, the entity, and the value object.

And generating aggregation according to the relation and the coupling degree between the business objects.

An aggregation is a boundary that can encapsulate one or more entities and value objects and maintain business integrity within the boundary. In the aggregation, at least one entity is included, and only the entity can serve as an aggregation root.

S105: the domain model is built by aggregating roots, entities, value objects, aggregations, domain services, and domain events.

The domain model is an abstraction of a problem domain, is also called a problem domain model, expresses a reality or abstract concept of a certain domain, and reflects essence of user service requirements in the domain; the domain model only reflects services, is irrelevant to any technical implementation, and not only can reflect some entity concepts in the domain, such as clients, electric energy meters, meter reading records, addresses and the like, but also can reflect some process concepts in the domain, such as account transfer and the like.

The domain model runs through the whole process of software analysis, design and development; the domain experts, the designers and the developers communicate through the domain model, share knowledge and information mutually, the requirement aliasing is prevented, and the software made by the software design developers can really meet the requirement.

The specific process of constructing the domain model is as follows:

the first step is as follows: an aggregate root is identified. After the object is determined, the aggregation root is identified according to the following principle according to the characteristics of the aggregation root.

(1) From the perspective of the identification. The aggregation root has a globally unique identification.

(2) From a read-only perspective. All state information of the aggregation root except for the unique identification is theoretically variable.

(3) From a life cycle perspective. The polymeric root has an independent life cycle.

The second step is that: an entity is identified. Entities are identified as follows.

(1) From the perspective of the identification. An entity has a unique local identity only within the aggregate.

(2) From a read-only perspective. The entities are variable.

(3) From a life cycle perspective. The life cycle of an entity is subordinate to the aggregation to which the entity belongs, and the entity is completely responsible for management and maintenance by the aggregation root to which the entity belongs.

The third step: a value object is identified. The value object is identified as follows.

(1) From the perspective of the identification. The value object has no unique identification and there is no saying of this value object or that value object.

(2) From a read-only perspective. The value objects are read-only.

(3) From a life cycle perspective. The value object is not lifecycle because there is only one value, i.e., the value object has invariance.

For example: when the customer is mailed with the bill for electricity, the customer address is needed, and the customer address is a value object.

The fourth step: and determining the polymerization. And identifying according to the coupling degrees of the aggregation root, the entity associated with the aggregation root, the value object and the like to form the aggregation. The structure of a specific polymerization is shown in FIG. 2.

In fig. 2, a client (aggregation root), a client address (value object), a client category (entity), an individual (entity), and an organization (entity) are an aggregation.

In FIG. 2, the solid oval boxes are bounding contexts and the dashed oval boxes are aggregations.

In fig. 2, the aggregation root is divided into boundaries, and an internal object of the aggregation root is a client (aggregation root); objects outside the aggregation root are the client role (aggregation root) and the client contact (aggregation root).

In fig. 2, the client (root of aggregation) is associated with the client role (root of aggregation) and the client contact (root of aggregation) by the client ID.

The fifth step: and (5) designing a model in the field. Establishing a relationship between aggregation and aggregation, for example, establishing a relationship between a client aggregation root and a client role aggregation root and a client contact aggregation root through a client ID; in the design process, aiming at the field behaviors which are not suitable for being established on the aggregation root and the entity, the field service is designed to be realized; in the design process, if it is found that after an action occurs, other domain objects associated with the action are affected, the action may be designed as a domain event.

Wherein, the domain event is a special object.

For convenience of understanding, if it is found that after an action occurs, other domain objects associated with the action are affected, the action may be designed as a process of domain event, which is exemplified here.

For example, if the A action is classified as an a object and the A action is classified as a b object, or if the A action is not suitable for being classified as an a object and the A action is not suitable for being classified as a b object, the A action is designed as a domain event.

S106: automatically checking the domain model; automatic verification is used for improving the precision of the field model.

In S106, the domain model is verified through a domain model verifier and a preset rule; the domain model positioner is used for positioning the error position of the domain model; the preset rules are used to ensure correctness, consistency and logicality of the domain model.

The preset rules comprise sub-domain check rules, field object attribute check rules, field object relation check rules and the like.

The automatic verification of the domain model may be described with reference to fig. 3, and fig. 3 is a schematic diagram illustrating the automatic verification of the domain model.

In fig. 3, the principle of the domain model verification apparatus is as follows: firstly, generating a 'UML model' in a memory by an EA builder according to an EA format model (an EA format model, eap and UML) needing to be checked, namely reading the EA format field model, and generating a UML in the memory after analyzing the EA format model by using an EA format analyzer; the domain model checker checks the domain model in the memory according to rules (a sub-domain check rule, a domain object attribute check rule, a domain object relation check rule and the like) established during design, reports an error when a problem exists, and generates a check analysis log; and the field model locator accurately locates error information of the field model in the memory, gives the error position of the field model and generates a check analysis log.

The role of the main subdomain and domain objects in the model test and management tool is as follows:

(1) builder contains the domain objects that read the eap file into the content.

(2) common is a common information subfield (packet).

(3) docgen contains the domain object that generated the word document.

(4) A model contains subdomains, domain objects, attributes, and the like.

(5) location includes the location where the related domain object is located.

(6) validation includes checking related domain objects.

(7) xml is related to xml-related classes.

The method and the device for verifying the domain model can verify the correctness, consistency and logicality of the domain model established by the EA tool, and can detect whether the established domain model is correct or not according to errors or warning information output by verification; whether the design of the subdomain, the domain object, the attribute, the relationship, the role and the cardinal number is strictly executed according to the standard can be automatically verified according to the established domain model design specification (subdomain, the domain object, the attribute, the relationship and the like); the positions of subdomains, field objects, attributes, relationships, roles and cardinality with design errors can be automatically positioned; the situation that different designers cannot find out the wrong position and the wrong reason due to the fact that the rules are not well understood or the rules are wrongly understood is avoided. At this time, the advantages of the domain model checking method and device can be fully embodied.

S107: and converting the verified domain model into a data model, and generating a data code through the data model.

Wherein, the data model is the database model.

The conversion of the verified domain model into the data model can be explained with reference to fig. 4, and fig. 4 shows a schematic diagram of the conversion of the domain model into the data model.

In fig. 4, the problem space is a structural feature of a problem to be solved for a problem existing in the real world. Features can be understood as simulated abstractions of the real world; it starts with the decomposition and organization of human beings into various concepts and relationships.

In domain-driven design, the partitioning of business systems is domain-based, i.e., business-based.

The solution space is a space formed by the structure of the computer and is a place where the problem is finally processed into a result, and each solution of the solution space is also created by human organization.

The process of converting the domain model into the data model is as follows:

and (1-1) analyzing and designing service requirements according to customer requirements.

And (1-2) designing a business model according to business requirements.

And (1-3) decomposing and identifying the service use case/system use case according to the service requirements and the service model.

(2-1) partitioning domains based on business needs and vision.

(2-2) in the field, the complex problem is decomposed, a plurality of subfields are generated, and a core subfield, a general subfield, and a support subfield are identified from the subfields.

(3) In a subdomain, a bound context is divided according to a service case and a system case, a boundary is determined, and the consistency of the universal languages in each bound context is ensured, so that the consistency of a domain model is ensured.

Wherein, the business requirement is abstracted to obtain the universal language.

(4) Collaboration between bound contexts is achieved through bound context mapping.

(5-1) abstracting the business object from the business model within a bound context.

And (5-2) abstracting the business object into a field object according to an abstraction method, identifying an entity, a behavior, a value object, a field service and a field event, and further checking, supplementing and perfecting through a use case. And identifying an aggregation root, a value object and an entity according to the service scene.

(6) The object relationships are determined by analysis.

The object relationships include one-to-one, one-to-many, many-to-many, inheritance relationships, and the like.

(7) And forming a domain analysis model by the core business objects.

Valuable domain knowledge is extracted through domain insights, and an abstract model which is beneficial to communication, namely a domain analysis model, is established.

(8) And analyzing the relation between the objects according to the aggregation root to identify the aggregation.

(9) The domain design model is composed of aggregation, domain objects, domain events, domain services, and the like.

Wherein, a domain design model is generated by taking the domain analysis model as a guide.

The domain design model is a technical evolution based on the domain analysis model, for example, the objects in the domain analysis model are assigned duties, an abstract interface completion module is established and the objects are decoupled, classes representing domain concepts are more reasonably encapsulated, unnecessary details are hidden, and design elements and modes proposed by Eric Evans are applied to the objects in the domain analysis model. In the domain design modeling phase, one learns to convert domain concepts (objects) in the domain analysis model into domain model objects in the domain design model.

(10) And converting the domain design model into a domain implementation model according to the domain design model, and generating a data code.

The domain implementation model is used for providing programming implementation following a domain design model, and at this time, a specific implementation mechanism needs to be considered, but the separation of business complexity and technical complexity needs to be kept, so that the superposition effect of the complexity is avoided. The field implementation model is represented by a programming language, different languages have different usages and different grammars, and even if different frames are selected under the same language, the field implementation model is different due to different design principles and ideas of the frames.

The domain analysis model, the domain design model and the domain implementation model form a domain model.

The domain implementation model can also be refined by bounding contexts.

(11) The data model is generated from the domain design model mapping.

(12) And dividing the service center according to the service model, the bound context, the object and the relationship.

The service center has the characteristics of high cohesion and low coupling, and the stability of system operation, the isolation of faults and the reasonability of resource allocation are ensured.

(13) Within the service center, a microservice (service model) is derived from a domain design model.

Among them, microservice is a variant of the Service Oriented Architecture (SOA) architectural style, which advocates dividing a single application into a set of small services, which are coordinated and coordinated to provide the final value to the user.

S108: the software development operation is performed by the data code.

Before software development, a large amount of business knowledge is usually required to be combed, and then the software design level is reached, and finally the software development is carried out. In the process of business knowledge combing, certain domain knowledge is formed necessarily, and software design is driven step by step according to the domain knowledge.

In the face of a large-scale complex informatization system, the field-driven design is a good solution, the basic idea of dividing and treating is adopted, the large complex problem is simplified into small problems, and then the field model design is carried out aiming at each small field.

The application provides a model design method and device in the field of power marketing based on power marketing business. A method system for designing the domain model is provided, the domain model design work is developed according to the design steps, and the method system has systematicness, integrity and guidance. A method for identifying the domain object is provided to guide a model designer to carry out the design work of the domain object. And a checking tool of the field model is designed and developed, and automatic checking and error accurate positioning of the designed field model are realized. The design of the domain model has a methodology foundation, the design method of the domain object can be based on, and the design result of the domain model has a tool for automatic verification.

In the embodiment of the application, a model designer is guided to carry out field object design work through a field object identification method, so that the field model development has a concrete implementation methodology basis, and the operation difficulty of the field model is reduced. And the field model is automatically checked, the error rate of checking the field model is reduced, and the accurate positioning of the error position of the field model is realized.

Based on the method for designing the model in the power marketing field disclosed in fig. 1 in the foregoing embodiment, the embodiment of the present application further discloses a device for designing the model in the power marketing field, as shown in fig. 5, the device for designing the model in the power marketing field mainly includes an obtaining unit 501, an abstraction unit 502, a first determining unit 503, a second determining unit 504, a building unit 505, a verification unit 506, a conversion unit 507, and an execution unit 508.

An obtaining unit 501, configured to obtain a service requirement, and create a service model according to the service requirement.

An abstraction unit 502, configured to abstract a service object from a service model; the business object is used for representing the business core object with preset key attributes.

A first determining unit 503, configured to determine a domain object based on the business object, and identify an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event from the domain object.

A second determining unit 504, configured to determine an aggregation based on the aggregation root, the entity, and the value object.

A building unit 505, configured to build a domain model through aggregation roots, entities, value objects, aggregations, domain services, and domain events; the domain model is a visual model of objects within the business context.

A checking unit 506, configured to perform automatic checking on the domain model; automatic verification is used for improving the precision of the field model.

The converting unit 507 is configured to convert the verified domain model into a data model, and generate a data code through the data model.

An execution unit 508 for performing software development operations through the data codes.

Furthermore, the abstraction unit comprises a first division module, a first identification module, a second division module and a first abstraction module.

The first division module is used for carrying out domain division according to the service requirements to obtain a plurality of sub-domains.

And the first identification module is used for identifying the service requirements and the service models to obtain service use cases and system use cases.

The second dividing module is used for dividing a limit context through a service use case and a system use case in a plurality of subdomains; a bounding context is a boundary on semantics and context; the boundaries are used to ensure consistency of the domain model.

And the first abstraction module is used for abstracting the business object from the business model based on the limit context.

Further, the electric power marketing field model design device further comprises an identification unit.

An identification unit for identifying the core, generic and support sub-domains from the sub-domains.

Further, the first determining unit 503 includes a second abstraction module and a second identification module.

And the second abstraction module is used for abstracting the business object into a field object by an abstraction method.

And the second identification module is used for identifying the aggregation root, the entity associated with the aggregation root, the value object associated with the aggregation root, the domain service and the domain event from the domain object through the business scene.

Further, the verification unit 506 is specifically configured to verify the domain model through a domain model verifier and a preset rule; the domain model positioner is used for positioning the error position of the domain model; the preset rules are used to ensure correctness, consistency and logicality of the domain model.

In the embodiment of the application, a model designer is guided to carry out field object design work through a field object identification method, so that the field model development has a concrete implementation methodology basis, and the operation difficulty of the field model is reduced. And the field model is automatically checked, the error rate of checking the field model is reduced, and the accurate positioning of the error position of the field model is realized.

While, for purposes of simplicity of explanation, the foregoing method embodiments have been described as a series of acts or combination of acts, it will be appreciated by those skilled in the art that the present application is not limited by the order of acts or acts described, as some steps may occur in other orders or concurrently with other steps in accordance with the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. For the system-class embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The steps in the method of the embodiments of the present application may be sequentially adjusted, combined, and deleted according to actual needs.

Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims (10)

1. A design method of a model in the field of power marketing is characterized by comprising the following steps:

acquiring a service demand, and creating a service model according to the service demand;

abstracting a business object from the business model; the business object is used for representing a business core object with preset key attributes;

determining a domain object based on the business object, and identifying an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service and a domain event from the domain object;

determining an aggregation based on the aggregation root, the entity, and the value object;

building a domain model from the aggregation root, the entity, the value object, the aggregation, the domain service, and the domain event;

automatically checking the domain model; the automatic verification is used for improving the precision of the domain model;

converting the verified domain model into a data model, and generating a data code through the data model;

and executing software development operation through the data codes.

2. The method of claim 1, wherein abstracting a business object from the business model comprises:

performing domain division according to the service requirements to obtain a plurality of sub-domains;

identifying the service requirements and the service model to obtain a service use case and a system use case;

in the plurality of sub-domains, dividing a bound context by the business use case and the system use case; the bounding context is a boundary on semantics and context; the boundary is used for ensuring the consistency of the domain model;

abstracting a business object from the business model based on the bound context.

3. The method of claim 2, further comprising:

a core subdomain, a common subdomain, and a support subdomain are identified from the subdomains.

4. The method of claim 1, wherein determining a domain object based on the business object and identifying an aggregation root, an entity, a value object, a domain service, and a domain event from the domain object comprises:

abstracting the business object into a domain object by an abstraction method;

identifying, from the domain objects, an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event through a business scenario.

5. The method of claim 1, wherein the automatically verifying the domain model comprises:

verifying the domain model through a domain model verifier and a preset rule; the domain model locator is used for locating the error position of the domain model; the preset rules are used for ensuring the correctness, consistency and logicality of the domain model.

6. A design device of a model in the field of electric power marketing, the device comprising:

the system comprises an acquisition unit, a service model creating unit and a service model creating unit, wherein the acquisition unit is used for acquiring service requirements and creating a service model according to the service requirements;

the abstraction unit is used for abstracting a business object from the business model; the business object is used for representing a business core object with preset key attributes;

a first determining unit, configured to determine a domain object based on the business object, and identify an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service, and a domain event from the domain object;

a second determining unit to determine an aggregation based on the aggregation root, the entity, and the value object;

a building unit to build a domain model through the aggregation root, the entity, the value object, the aggregation, the domain service, and the domain event;

the verification unit is used for automatically verifying the domain model; the automatic verification is used for improving the precision of the domain model;

the conversion unit is used for converting the verified domain model into a data model and generating a data code through the data model;

and the execution unit is used for executing software development operation through the data codes.

7. The apparatus of claim 6, wherein the abstraction unit comprises:

the first division module is used for carrying out field division according to the service requirements to obtain a plurality of sub-fields;

the first identification module is used for identifying the service requirements and the service model to obtain a service use case and a system use case;

a second partitioning module, configured to partition a bound context from the service use case and the system use case in the plurality of sub-domains; the bounding context is a boundary on semantics and context; the boundary is used for ensuring the consistency of the domain model;

a first abstraction module to abstract a business object from the business model based on the bound context.

8. The apparatus of claim 7, further comprising:

an identification unit for identifying a core sub-domain, a general sub-domain and a support sub-domain from the sub-domains.

9. The apparatus of claim 6, wherein the first determining unit comprises:

the second abstraction module is used for abstracting the business object into a domain object by an abstraction method;

and the second identification module is used for identifying an aggregation root, an entity associated with the aggregation root, a value object associated with the aggregation root, a domain service and a domain event from the domain objects through a business scene.

10. The apparatus according to claim 6, wherein the verification unit is specifically configured to:

verifying the domain model through a domain model verifier and a preset rule; the domain model locator is used for locating the error position of the domain model; the preset rules are used for ensuring the correctness, consistency and logicality of the domain model.

Images