CN113592647A - Transaction method and system based on domain model abstraction - Google Patents

Abstract

The invention provides a transaction method based on field model abstraction, which comprises the following steps: constructing a transaction related party object; constructing a document container according to the service scene; establishing transaction payment according to the business fund and the transaction related party object; and constructing a transaction verification and cancellation bill according to the business fund and the bill container transaction bill. The invention has the beneficial effects that: the functional design of the transaction type management information system is redefined, the traditional design mode which takes concrete functions as key points is changed, the transaction method and the system are abstracted into transaction related party objects, business transactions and transaction bills by adopting an abstract design mode based on a domain model, the change in the enterprise process can be well solved, and modularization, combination and pluggable can be realized.

Description

Transaction method and system based on domain model abstraction

Technical Field

The invention relates to the technical field of transaction, in particular to a transaction method and a system based on domain model abstraction.

Background

The traditional transaction type software system mainly solves the problems of service change and flexibility through the complexity of technical architecture, such as: the functional modules are divided according to business requirements or business scenes, and a micro-service and distributed technical architecture is adopted, so that the flexibility of a set of system in an actual application scene depends on the functional architecture. The functional architecture of the conventional system has two main modes: one mode is a system constructed based on specific functions, the system can solve complex business rules, but the functions are relatively solidified, the capability and efficiency of responding to changes are low, and the required development period is long; the other mode is a low-code development platform, the system can quickly construct the system and respond to the change of the service in a configuration mode, but for some more complex service requirements, the more complex service requirements cannot be realized in a configuration mode and need to be realized by coding, so that the system is not suitable for the requirements of complex transaction type systems.

The trading type business is characterized in that the business changes frequently, and in an actual business scene, the changes of enterprises are caused by market changes, so that the changes are uncertain and unpredictable, and the changes are changes in channel relations, business modes, organizations, trading structures and the like. In the traditional mode, a software system needs certain certainty to be designed and realized. Thus, the deterministic requirements of the software conflict with the uncertain changes of the enterprise, making it difficult for the software system to meet the enterprise's needs in a large number of practical processes. Meanwhile, the responsiveness of the transaction-type service to the system is high, the changes need to be realized through a large amount of codes in the traditional mode, the design, development and test periods cannot meet the requirement of the service on the effectiveness, and the situation that the traditional software with the configuration function cannot be completely met due to incomplete configuration functions can also occur.

Therefore, the business under the trading scene is constantly changing, and how to efficiently meet the business change is a difficulty of the current trading software.

Disclosure of Invention

The invention provides a trading method and a trading system based on domain model abstraction, which solve the problems in the prior art.

The technical scheme of the invention is realized as follows:

a trading method based on domain model abstraction, comprising:

constructing a transaction related party object;

constructing a document container according to the service scene;

establishing transaction payment according to the business fund and the transaction related party object;

and constructing a transaction verification and cancellation bill according to the business funds and the bill container.

Further, the constructing of the transaction related party object includes constructing a GUID, constructing a transaction related party type, constructing a transaction related party name, and constructing a plurality of transaction related party roles.

Further, constructing a number of transaction-related party roles includes:

constructing a PRID;

constructing a role state of a transaction related party and role form data of the transaction related party according to business requirements;

and establishing a role workflow of a transaction related party according to the approval requirement.

Furthermore, the role form data of the transaction related party comprises a main form and a plurality of sub forms, and the main form stores and synchronously updates the sub form data.

Preferably, the sub-forms are individual web pages.

Further, the step of constructing the document container comprises constructing a document container number, constructing a document container name, constructing a document container state and constructing a transaction document set, wherein the transaction document set comprises a plurality of transaction documents.

Further, the establishing of the transaction document set comprises associating the transaction related party object, establishing a transaction document number, establishing a transaction document name, establishing a transaction document state, establishing a transaction document component and establishing a transaction document workflow.

Further, the establishing of the transaction payment comprises establishing a transaction payment number, establishing a transaction payment state, establishing a transaction payment price item, establishing a transaction payment date, establishing a transaction payment partner, establishing a transaction payment reimbursement history and establishing a transaction payment workflow, wherein the transaction reimbursement bill is associated with the transaction payment reimbursement history.

Further, the step of constructing the transaction verification and sale bill comprises the steps of constructing a transaction verification and sale bill number, constructing a transaction verification and sale bill state, constructing a transaction verification and sale bill partner, constructing a transaction verification and sale bill price item, constructing a transaction verification and sale bill rule and constructing a transaction verification and sale bill workflow.

A trading system based on the trading method based on the domain model abstraction as described above, comprising:

the transaction related party object module is used for constructing a transaction related party object and creating transaction related party object data;

the business transaction module is used for constructing business transaction by constructing a bill container and constructing transaction payment, creating business transaction data and connecting the business transaction data with the transaction related party object module;

and the transaction bill module is used for constructing a transaction verification bill and is connected with the transaction related party object module and the business transaction module.

The invention has the beneficial effects that:

according to the field model abstraction-based transaction method and system, the functional design of the transaction type management information system is redefined, the traditional design mode with concrete functions as key points is changed, the field model-based abstract design mode is adopted, the transaction method and system are abstracted into transaction related party objects, business transactions and transaction bills, the change in the enterprise process can be well solved, and modularization, combination and pluggable can be realized.

Drawings

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

FIG. 1 is a flow chart illustrating the steps of a transaction method based on domain model abstraction according to 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.

As shown in fig. 1, a transaction method based on domain model abstraction according to the present invention includes:

constructing a transaction related party object;

constructing a document container according to the service scene;

establishing transaction payment according to the business fund and the transaction related party object;

and constructing a transaction verification and cancellation bill according to the business funds and the bill container.

The method comprises the steps of establishing a transaction related party object, establishing a type of the transaction related party, establishing a name of the transaction related party and establishing a plurality of roles of the transaction related party, namely the transaction related party object has one or more roles of the transaction related party according to the identity of the transaction related party object in the business process, the transaction related party object and the roles of the transaction related party are in one-to-many relationship, and the transaction related party object and the roles of the transaction related party have different information under different roles of the transaction related party as the same transaction related party object.

Wherein, preferably, the transaction-related party types include natural persons, legal persons and organizations; the name of the transaction related party comprises a natural person name or a legal person name; the transaction-related party roles include customer, distributor, and provider.

Wherein, the step of constructing the roles of the transaction-related parties comprises the following steps:

constructing a PRID;

constructing a role state of a transaction related party and role form data of the transaction related party according to business requirements;

and establishing a role workflow of a transaction related party according to the approval requirement.

Specifically, the GUID is a globally unique identifier of the transaction-related party object; the PRID is a global unique identifier of a role of a transaction related party and is unique in the system, and the PRID is a primary key ID of the role of the transaction related party and is used for being associated with an object of the transaction related party; the role of the transaction related party is a business role of a specific transaction related party object in a transaction scene, and the definition of the role is set according to the business scene, for example: the invention relates to a method for realizing the business function of a plurality of business related party objects, in particular to a method for realizing the business function of the business related party objects, which is characterized in that one business related party object can simultaneously have a plurality of business related party roles, namely, in a specific business scene, a specific legal person can be a dealer role or a client role, and the situation is common in actual business.

Specifically, the role status of the transaction-related party is used for managing the status of the role of the transaction-related party in the business process, for example: creating, approving, starting, canceling, invalidating and the like, and the specific role state list of the relevant parties of the transaction is formulated according to the actual service scene.

Specifically, the transaction-related party role form data is used for storing data of corresponding transaction-related party roles, and this structure enables different transaction-related party roles to have respective data structures, when one transaction-related party object possesses multiple roles at the same time, for example: the system comprises a dealer and a client, wherein the data contents of the dealer and the client are different under the roles of the dealer and the client, the role form data of a transaction related party comprises a main form and a plurality of sub-forms, the main form stores and synchronously updates the sub-form data, and each sub-form is an independent web page and is used for meeting the requirements of the roles of the transaction related party under specific scenes such as examination, approval and change; the role workflow of the transaction related party is used for supporting a specific business approval process, under the scene of role change of the transaction related party, the main form is used for storing all data of roles of the transaction related party, the sub-forms are used as information change application forms, and after the information change application forms are approved, the data needing to be changed can be updated into the main form. By adopting the mode, when the role data of the transaction related party is changed and needs to be approved, the original data is not influenced in the approval process, and after the change is completed, the data can be updated, and meanwhile, the change history can be kept by changing the sub-form.

In a practical scenario, the construction process of the transaction related party object is as follows.

And constructing the role of a transaction related party according to the service scene, such as: dealers, customers, etc.;

and constructing the role state of the transaction related party according to the business requirements, such as: newly creating, validating and invalidating, and constructing trading related party role list data required by trading related party roles according to business requirements so as to record information required to be recorded by the trading related party roles;

selectively constructing a sub-form according to the requirement of business complexity, and constructing the sub-form if the requirements such as change, examination and approval exist;

and finally, establishing a role workflow of a transaction related party according to the approval requirement, wherein the role workflow of the transaction related party is realized by adopting a process engine technical component.

Thus, the construction of the transaction-related party object has been completed and the particular transaction-related party object data can be used in the transaction order upon its creation. All objects in the business process are transaction related party objects, business transactions generated by the transaction related party objects are represented as an order, and the receivable and payable relations generated by the transactions are transaction bills.

The process of transaction-related party object data creation is as follows:

establishing a new transaction related party object;

selecting a transaction-related party role, for example: dealers, customers, etc.;

then selecting the types of roles of the related parties of the transaction, such as natural persons, legal persons, organizations and the like;

filling relevant business data according to role form data of a transaction relevant party, and representing the state of the data by changing the state of the form, such as: newly building, taking effect and making waste;

if the role workflow of the transaction related party is created, the role workflow of the transaction related party is circulated in the role of the transaction related party according to the configuration of the role workflow of the transaction related party until the execution of the role workflow of the transaction related party is finished, and the state of the workflow in the execution process changes along with the flow node.

The method comprises the steps of establishing a document container number, establishing a document container name, establishing a document container state and establishing a transaction document set, wherein the transaction document set comprises a plurality of transaction documents.

The method comprises the steps of establishing a transaction document set, wherein the transaction document set comprises the steps of associating transaction related party objects, establishing transaction document numbers, establishing transaction document names, establishing transaction document states, establishing transaction document components and establishing transaction document workflows.

Specifically, the transaction document number is unique in the whole situation; the name of a transaction document is used to describe the business meaning of the transaction document, for example: business application form, contract order form, delivery form, etc.; the state of the transaction document is used for managing the state of the transaction document, and the data structure of the state of the transaction document comprises: state identification, state description, preorder state and editing control, wherein the state description comprises new creation, approval passing, invalidation and the like, and the editing control comprises editable and non-editable; the transaction document assembly is an organization form of data in the transaction document, the data in the transaction document is divided into different data groups, different data are realized in a transaction document assembly mode, the transaction document assembly is finally configured into the transaction document through a configuration function, the expression form of the transaction document assembly comprises document basic information, product information, price information and the like, wherein the document basic information comprises contract numbers, service types and the like, the product information comprises product names, models, unit prices, quantity, total amount and the like, and the price information comprises product amount, service fees, discount proportions, final quotes and the like; the data structure of the transaction document component comprises a component identification, a component name, a component description, a calculation sequence and an editing control; the transaction document workflow is used for managing the approval flow of the transaction document, a workflow engine mode is adopted in the technical implementation aspect, the flow is drawn according to business requirements, then the flow is related to the transaction document, and the data structure of the transaction document workflow comprises the following steps: a process number, a start state, and a terminate-rollback state, wherein the process number is taken from the process instance ID in the workflow engine. The transaction bill set is used for managing the details of the transaction bills contained in the bill container and managing the front-back order relationship among the transaction bills, the bill container and the transaction bills are in one-to-many relationship, and the transaction bill set can comprise the following fields: the method comprises the steps of (1) transaction receipt number, transaction receipt name, pre-transaction number, pre-transaction state and extension program; the transaction document is used for managing transaction activities among transaction-related party objects, and the essence of a transaction-type transaction is a set of transaction activities formed by a set of transaction-related party objects, such as: each transaction link is participated by a plurality of transaction related party objects, and the transaction documents are used for recording transaction data, transaction processes, transaction algorithms, transaction program processing logic and the like among the transaction documents.

Specifically, the document container number is globally unique; the document container name is used to describe the actual meaning of the container, and in the usage scenario, the service type may be used as the container name, for example: retail business, rental business, insurance business, etc.; the document container status is used to manage the phase status of the business, for example: an application stage, an approval stage, a signing stage, an execution stage, completion, invalidation, cancellation and the like; the document container is used for packaging a set of transaction documents and managing the front-to-back order relation between the transaction documents, and the transaction documents packaged by the document container can meet the requirement of a specific scene service, so the document container can be used for packaging the service scene. Based on the characteristic, the invention can support multiple business transactions in one system, and simultaneously, multiple business scenes have respective transaction receipts, thereby effectively controlling the functional coupling association between the business scenes.

By constructing a document container and constructing transaction payment, a business transaction can be constructed, and the specific process is as follows:

according to the requirements of a business scene and the construction and combing of transaction related party objects in the scene, the specific business modes contained in the business scene are analyzed, and each business mode is respectively created into a receipt container, namely a business type, for example: retail business, rental business, wholesale business, etc.;

analyzing the business transaction process contained in each business type, namely the business main line business flow, for example: business application forms, contract orders, delivery forms and the like, wherein each transaction process forms a transaction document;

defining the state of the transaction document in the transaction document, for example: new construction, passing, making a waste and the like;

defining a role of a transaction related party, which is used for managing the role of the transaction related party related to the transaction document;

defining a transaction document component for managing data in the transaction document;

and constructing a transaction document workflow according to business requirements, wherein the step can be defaulted according to actual conditions.

By this point, the business transaction has been completed.

The process of business transaction data creation is as follows:

selecting a certain service type scene to create a service, for example, creating a transaction process of a retail service, and selecting a retail service type; then, creating a service application form; creating a contract order after the service application order is created; establishing an invoice after a contract order is established; and finishing all the transaction documents according to the constructed flow.

The transaction payment construction method comprises the steps of constructing a transaction payment number, a transaction payment state, a transaction payment price item, a transaction payment date, a transaction payment partner, a transaction payment reimbursement history and a transaction payment workflow, wherein the transaction reimbursement bill is associated with the transaction payment reimbursement history;

the step of constructing the transaction verification and sale bill comprises the steps of constructing a transaction verification and sale bill number, constructing a transaction verification and sale bill state, constructing a transaction verification and sale bill partner, constructing a transaction verification and sale bill price item, constructing a transaction verification and sale bill rule and constructing a transaction verification and sale bill workflow.

Specifically, the transaction payment object takes the service fund as a dimension, and one piece of data represents one payment amount of a transaction related party; the transaction payment number is a fund number which is unique in the whole situation; the transaction payment state is a state defined for funds according to the actual needs of the transaction, such as: to be confirmed, checked, voided, returned, etc.; the transaction payment price term is used to manage the amount of funds and other related data, such as: the amount of money to be paid, the amount of money to be checked and the remaining amount of money can be added with new price items according to the actual business scene; the transaction payment date is used to record date information associated with the funds, such as: account arrival time, payment time, verification and cancellation time and the like; the transaction payment partner is used for managing a payer and a payee of the fund, and managing the payee of the fund in a transaction partner mode; the transaction payment and reimbursement history is associated with the reimbursement process of the fund, the mapping relation between the fund and the reimbursement bill is a one-to-many relation, and each fund can be reimbursed for many times until the residual amount is zero; the transaction payment workflow may be embedded in a transaction payment document for satisfying the user's requirements for the approval flow.

Specifically, the transaction reimbursement note number is the number of the transaction reimbursement note and is unique in the overall situation; the transaction invoice status is used to mark the transaction status of the transaction invoice, for example: newly built, submitted, audited and invalidated; the transaction verification and sales bill partner is used for recording the receiving and paying related parties of the transaction verification and sales bill; the transaction invoice price item is used to manage invoice-related amount data, such as: the amount of money to be paid, the amount of money to be checked and the remaining amount of money can be added with new price items according to the actual business scene; the transaction verification and cancellation bill rule is used for associating relevant price information in the transaction receipt, the bill verification and cancellation rule is defined, and the mapping relation between the transaction verification and cancellation bill and the transaction receipt is a one-to-many relation; the transaction verification and cancellation sheet workflow can be embedded in the transaction verification and cancellation sheet and used for meeting the requirements of users on the approval flow.

The construction process of the transaction bill is as follows:

creating a transaction payment data;

carrying out fund payment operation, and selecting a payer and a payee of the fund to determine a receiving and paying object of the fund;

and creating a transaction verification order under the transaction payment, associating a transaction document to be verified in the transaction verification order, displaying data to be verified after selection, selecting receivable items to be verified, and recording the rest of the funds in the rest amount. Creation of a new transaction statement may continue until the funds balance is zero.

The transaction bill includes a payer and a payee, both of which may be a multi-party relationship centered on the order, for some business scenarios, for example: interest is the case of multiple parties at the payer, and joint lease is the case of multiple parties at the payee.

A trading system based on the trading method based on the domain model abstraction as described above, comprising:

the transaction related party object module is used for constructing a transaction related party object and creating transaction related party object data;

the business transaction module is used for constructing business transaction by constructing a bill container and constructing transaction payment, creating business transaction data and connecting the business transaction data with the transaction related party object module;

and the transaction bill module is used for constructing a transaction verification bill and is connected with the transaction related party object module and the business transaction module.

The invention relates to a trading method and a trading system based on field model abstraction, which redefines the functional design of a trading type management information system, changes the traditional design mode taking concrete functions as key points, adopts an abstract design mode based on a field model to abstract the trading method and the system into trading related party objects, business trades and trading bills, wherein the change of an enterprise in an actual business scene is changed according to market change and has the characteristics of frequent and unpredictable, the management information system is often adjusted along with the change of the enterprise, and the traditional management information system is often designed based on the concrete functions, so that the requirements of the enterprise on the functional flexibility and the change efficiency are difficult to meet.

The transaction related party object function can well solve the change of an enterprise on the channel and mode level, when a new channel party and a new transaction object appear in a business, only a new transaction related party role needs to be added under the architecture of the method and the system, and meanwhile, the transaction related party role is associated to the corresponding transaction receipt function, and a series of functions of adding, deleting, modifying and checking and basic information management functions of related parties do not need to be added in a traditional mode;

the transaction receipt function realizes loose coupling among all links in the business transaction process through the front and rear association functions, can be easily supported when the links of the transaction flow are increased, reduced and adjusted, and has less association influence on other links;

the transaction bill function can manage a business link corresponding to the transaction bill and a payer and a payee of the transaction bill through matching with the transaction document and the object function of a transaction related party, can support a complex scene that a plurality of payers and payees exist in one transaction bill, can realize business and financial integration by butting data of the transaction bill function with the financial system, and assists the financial system to automatically generate financial certificates.

The field model abstraction-based transaction method and system can well solve the change in the enterprise process and can realize the following steps:

1. modularization: the system functions adopt a modular design, and better services are provided for services through good function division;

2. assembling: the coupling performance of the functions is reduced through modular design, the reusability of the functions is improved, and a specific transaction document and related functions can be quickly built by adopting a modular development mode;

3. combination type: the business mode and the business process are formed by combining modules and components, and flexible system functions are provided for the business;

4. pluggable: the functional modules and functional components can be replaced, adjusted and removed according to business needs, and other business functions are not influenced.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.

Claims (10)

1. A transaction method based on domain model abstraction is characterized by comprising the following steps:

constructing a transaction related party object;

constructing a document container according to the service scene;

establishing transaction payment according to the business fund and the transaction related party object;

and constructing a transaction verification and cancellation bill according to the business funds and the bill container.

2. The domain model abstraction-based transaction method of claim 1, wherein building transaction-related party objects includes building GUIDs, building transaction-related party types, building transaction-related party names, and building several transaction-related party roles.

3. The domain model abstraction-based transaction method of claim 2, wherein constructing a number of transaction-related party roles comprises:

constructing a PRID;

constructing a role state of a transaction related party and role form data of the transaction related party according to business requirements;

and establishing a role workflow of a transaction related party according to the approval requirement.

4. The field model abstraction-based transaction method of claim 3, wherein the transaction related party role form data includes a main form and a plurality of sub forms, and the main form stores and synchronously updates the sub form data.

5. The domain model abstraction-based transaction method of claim 4, wherein the sub-form is a separate web page.

6. The field model abstraction-based transaction method of claim 1, wherein constructing a document container includes constructing a document container number, constructing a document container name, constructing a document container state, and constructing a transaction document set, the transaction document set including a plurality of transaction documents.

7. The field model abstraction-based transaction method of claim 6, wherein constructing a transaction document set includes associating transaction related party objects, constructing a transaction document number, constructing a transaction document name, constructing a transaction document state, constructing a transaction document component, and constructing a transaction document workflow.

8. The domain model abstraction-based transaction method of claim 1, wherein building transaction payments includes building transaction payment numbers, building transaction payment states, building transaction payment price terms, building transaction payment dates, building transaction payment partners, building transaction payment reimbursement histories, and building transaction payment workflows, the transaction reimbursement order being associated with the transaction payment reimbursement histories.

9. The domain model abstraction-based transaction method of claim 8, wherein constructing a transaction invoice comprises constructing a transaction invoice number, constructing a transaction invoice state, constructing a transaction invoice partner, constructing a transaction invoice price term, constructing a transaction invoice rule, and constructing a transaction invoice workflow.

10. A trading system based on the trading method based on the domain model abstraction of claim 1, comprising:

the transaction related party object module is used for constructing a transaction related party object and creating transaction related party object data;

the business transaction module is used for constructing business transaction by constructing a bill container and constructing transaction payment, creating business transaction data and connecting the business transaction data with the transaction related party object module;

and the transaction bill module is used for constructing a transaction verification bill and is connected with the transaction related party object module and the business transaction module.

Images