Domain Model: the virtual reality of Business Request and the design pattern of Business Action
Author: Anders James
Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/09/19/70643.html
In Domain Object: Analysis Based on Business behavior, I propose that from the high level perspective, a Business Process consists of three models: Business Request, Business Process, and Business Action. In actual design, Business Request and Business Action will be refined.
The real-world approach to Business Request
The concept of Business Request is different from that of http request. To avoid misunderstanding, add the word "Business.
The so-called virtual reality refers to whether to instantiate the Business Request concept. It is easy to process without instantiation. instantiation helps to process Business Transaction and the account mode.
A Business Request may contain multiple Request forms that correspond to core Business objects. For example, an online order includes the purchased items, their quantity, and discounts, payment Agreement and delivery agreement.
If the Business Request is not instantiated, a physical transaction is required for each form operation during actual Business operations.
The problem is that, because the Business Request is not recorded and the Business Object is operated directly, the Business Log can only record the information before and after the operation ("before losing weight, "); at the same time cross multiple transactions, to support querying all the operation information of a Business Request, you need to create a new log index or similar means, obtain and register an index at the beginning of the business. Reference this index in all log operations and close the index after the business ends. However, it also brings inconvenience to undo and redo operations on the business.
However, if the Business Request is instantiated, the two operations can be easily processed. Create a Business Request and record the Request Form involved. The advantage of doing so is that it is easy to record some additional information, and it is easy to support the approve operation (the so-called "Account Management regardless of money, "). However, most systems do not currently process Business Request instantiation. Not all Business operations require Approve. In addition, the trouble of Instantiation is that the Request Form will look the same as the Domain Object, A log object has been processed, and processing a request object is always a bit uncomfortable. Page processing needs to extract the changed properties.
Business Action Design Model
In short, the Business Action is refined into action controller and concrete action. At this level, action has three Pattern types known for request Response Processing:
The differences among Observer Pattern, Chain of responsibility Pattern and Pipes and Filters Pattern are discussed below:
| Name |
Dispatch Mode |
Actions Relation |
Controller |
| Observer Pattern |
The request and action are one2pipeline
Multicast deliver |
Each action works independently.
Share the same input |
Action register to Controller, Controller visit Action |
| Chain of Responsibility |
The request and action are one2one.
Chained deliver |
Each action works independently. |
Controller poll actions |
| Pipes and Filters |
The request and action are one2pipeline
Piped deliver |
Cooperation between various actions
Share the same work data |
Controller iterate actions |
The three pattern processes different scenario.
The alias of Pipes and Filters is Data Flow Pattern, which is suitable for processing large amounts of Data.
