table of Contents
Domain Driven Design - Lifecycle object
Each object has a life cycle, shown in Figure 6-1. Since the object is created, it may experience a variety of different states, until the final demise - either archived or deleted. Of course, many objects are simple temporary objects, only created by calling the constructor, to do some calculations, and then recovered by the garbage collector. Such objects do not need to do that complicated. However, some objects have a longer life cycle, which is not part of the time spent in active memory. They have complex interdependencies with other objects. They will experience some change of state at the time of the change to comply with some fixed rules. Face many challenges when managing these objects, the slightest mistake will deviate MODEL-DRIVEN DESIGN track.
The main challenge in the following categories.
(1) maintaining the integrity of the entire life cycle.
(2) prevent the model from the troubled life cycle management complexity caused by them.
AGGREGATE to (polymerization), it is clearly defined by the boundaries and affiliations, and to avoid confusion, the intricate network of objects to achieve cohesive model. Aggregation mode has a crucial role in maintaining the integrity of the various stages of the life cycle. We turn our attention to the beginning of the life cycle, using FACTORY (factory) to create and reconstruct complex objects and AGGREGATE (polymerization), to encapsulate their internal structure. Finally, REPOSITORY (repository) in the middle and the end of the life cycle to provide search and retrieve persistent objects and packaging means a huge infrastructure.
Despite the REPOSITORY and FACTORY itself it is not derived from the field, but they play an important role in the field of design. These structures provide easy-to-grasp an object model approach, the MODEL-DRIVEN DESIGN more complete.
AGGREGATE using modeling, using FACTORY REPOSITORY and incorporated into the design, so that we can model the entire life cycle of the object in order to sense the cell, they manipulate the system. AGGREGATE can be divided into a range of model elements within this range at all stages of the life cycle should maintain its fixed rules. FACTORY and REPOSITORY AGGREGATE operate on the basis of the particular life cycle of the converted complex encapsulated.
AGGREGATE
Reduce the related design helps simplify traverse between objects, and to some extent limit the relationship of the sharp increase. But most business areas in objects have a very complex relationship that will ultimately lead to a long, deep object reference path, we have to track objects on this path. In part, this confusion reflects the real world, the real world because very few clear boundaries. But it is an important issue in software design.
Suppose we remove a Person object from the database. The person's name, date of birth and job descriptions are to be deleted altogether, but to address how to deal with it? There may be other people living at the same address. If you delete the address, those Person objects will be a reference to the object to be deleted. If you leave the address, the address of garbage will accumulate in the database. Although automatic garbage collection garbage can address, but this is only a technical repair; even if the existence of such a database system handling mechanism, a basic modeling problem remains ignored.
Even when considering the orphaned transaction, a typical object model networks also make it difficult to determine what the potential impact will produce a modification. Just because there is a dependency on each object in the system update, this is unrealistic.
In the system of multiple clients concurrent access to the same object, the problem is more prominent. While many of the objects in the system user to query and update, we must prevent them also modify interdependent objects. Range error will lead to serious consequences.
In models with complex association, in order to ensure the consistency of the object change it is very difficult. Not only unrelated objects need to comply with some fixed rules, and each group of closely related objects should follow some fixed rules. However, overly cautious locking mechanism will lead to senseless mutual interference between multiple users, making the system unusable.
In other words, how do we know an object by other objects of where to start, and where to end? In any system with a persistent data store, the data can be modified transaction must have range, but there must be a way to maintain data consistency (that is, to maintain data subject to fixed rules). It supports a variety of database lock mechanism, and can write some tests to verify. But these special solutions distracted attention from the model, and soon people will return to the "step, by step," the old road up.
In fact, in order to find a balanced solution to the various problems, it requires a deep understanding of the field, for example, to understand the deep-seated factors such as changes in frequency between the particular instance of the class. We need to find a conflict between objects so that fewer fixed rules more closely linked model.
Although the surface of this problem is a technical problem database affairs, but has its roots in the model, in the final analysis it is due to the lack of model boundaries clearly defined. Solutions derived from the model will model easier to understand and make the design easier to communicate. When the model is modified, it will lead us to make changes to achieve.
First, we need to refer to an abstract model of the package. AGGREGATE is a collection of related objects, we use as the data modification unit. Each AGGREGATE have a root (root) and a border (boundary). Boundary defines the internal AGGREGATE have anything. Root is a particular ENTITY AGGREGATE included. For AGGREGATE, the reference external object can only be the root, and between the objects can refer to each other inside the boundary. ENTITY other than the root has a local identity, but they only need to identify only be distinguished within the AGGREGATE, because the external object except the root ENTITY see other objects.
Auto repair shop software might use car model. Figure 6-2. ENTITY is a car with a global identity: we need to separate this car with all other car areas around the world (even some very similar car). We can use the vehicle identification number to distinguish, vehicle identification number is a unique identifier is assigned per new car. We may want to rotate to track the history of Ge tire by bit four wheels. We may want to know the mileage and wear of each tire. To know which tire where, the tire must be marked as ENTITY. When the car out of context, we probably will not care about the identity of these tires. If you replaced the tires and used tires to recycling plants, then the software will no longer need to track them, they will become part of a pile of scrap tires. No one will care about their rotation history. More importantly, even if the tire is safe in the car, no one would query a specific tire through the system, then take a look at this tire in which cars. People will find the car in the database, and then look at the temporary tire situation this car. Therefore, the car is AGGREGATE root ENTITY, while the tire is within the boundaries of the AGGREGATE this. On the other hand, above the engine block are engraved with a serial number, and are sometimes independent car being tracked. In some applications, the engine may be the root of their AGGREGATE.
Fixed rules (invariant) refers to the consistency rules that must be maintained when the data changes, it relates to the internal relationship between AGGREGATE members. And any rules across AGGREGATE will not be required at all times to date. By event processing, batch, or other update mechanisms, which rely on will be resolved within a certain period of time. However, when each transaction is completed, the internal AGGREGATE fixed rule applied must be met, shown in Figure 6-3.
Now, in order to achieve AGGREGATE on this concept, we need to apply a set of rules for all transactions.
ENTITY roots with a global identity, which is ultimately responsible for checking the fixed rules.
ENTITY root having global identity. ENTITY within the boundaries with local identity, which is the only identity only inside AGGREGATE.
AGGREGATE external object can not reference any objects inside the root outside ENTITY. ENTITY ENTITY can root for internal reference passed to them, but these objects are only temporary use of these references, references can not be maintained. Root can copy a VALUE OBJECT passed to another object without having to care about what changes it happen, because it's just a VALUE, no longer have any connection with the AGGREGATE.
As a corollary to the previous rule, only AGGREGATE root in order to get direct access through the database. All other objects must be found by traversing the association.
Objects can be kept inside the AGGREGATE references to other AGGREGATE roots.
Delete operation must delete all objects within AGGREGATE boundaries. (Use garbage collection mechanism, it is very easy to do because of other objects other than the root are no external references, so after deleting the root, other objects will be recovered.)
When submitting modifications to any object AGGREGATE internal borders, fixed rules across all AGGREGATE must be met.
We should ENTITY and VALUE OBJECT gathered AGGREGATE different categories and define the boundaries of each AGGREGATE. In each AGGREGATE, select ENTITY as a root, and controls access to all other objects within a boundary through the root. Only external object keeps a reference to the root. Temporary reference to the inner member can be passed out, but only valid in one operation. Because the root access control, and therefore can not bypass it to modify the internal object. This design helps ensure that objects AGGREGATE satisfies all fixed rules can also ensure that any changes AGGREGATE state as a whole to meet the fixed rules.
There can declare a technical framework AGGREGATE is helpful, so that you can implement automatic locking mechanisms and other features. Without such technology framework, the team must rely on self-discipline to use pre-agreed AGGREGATE, and in accordance with these AGGREGATE to write code.
Examples of the integrity of purchase orders
A typical purchase order (Purchase Order, PO) view, it is broken down into procurement items (Line Item), a fixed rule is the total purchase items can not exceed the limit of the total PO. The current implementation of the following three interrelated issues.
Embodiment (1) of the fixed rule. When adding a new purchase items, total PO check if the new term for a total purchase exceeds the limit, then the PO marked as invalid. As we shall see, this protection mechanism is not sufficient.
(2) change management. When the PO is deleted or archived, each purchase items will also be a process, but did not give a model where relationship should stop. Change parts (Part) affect prices at different times produced is not clear.
(3) database sharing. Database problems caused by the use of a plurality of users will be brought.
The plurality of users to enter and update each concurrently PO, they must be prevented from interfering with each other. Let's start with a very simple strategy, when a user starts editing any object, the object is locked until the user commits the transaction. Thus, when George editing procurement item 001, Amanda can not access it. Amanda can edit any purchase other items on the PO (including other procurement items on George being edited PO)
Each user is read from the database objects, and instantiate an object in its own memory space, then view and edit the object there. Only when you start editing, database requests will be locked. Therefore, George and Amanda can work at the same time, as long as they do not simultaneously edit the same item to purchase. Everything is normal, until you start editing a different George and Amanda purchase items on the same PO.
From the perspective of both users and their respective software point of view, their operations are not a problem, because they ignore the rest of the database changes during the transaction occurred, and each user can not modify locked purchase other items. When two users save changes, the database is stored in a fixed domain model PO violate the rules. An important rule of business is destroyed, but no one knows
Obviously, locking a single row is not an adequate protection mechanism. If a lock a PO, you can prevent such problems
Until Amanda solve this problem, the program will not be allowed to save the transaction, Amanda can resolve this problem by increasing the quota or reducing a guitar. This mechanism prevents the problem if most of the work spread across multiple PO, then this may be a good solution. But if a lot of people at the same time on different items were a large PO operation, this locking mechanism becomes very awkward.
Even many small PO, there are other means to sabotage this fixed rules. Let's see "Part". If the trombone when Amanda to the order and someone changed the price trombone, which will not destroy the fixed rules?
In addition we tried to lock the entire PO addition, also locked Part, the case when George, Amanda and Sam work on different PO will happen.
Work has become more and more troublesome, because there have been many cases of contention in Part. Such results would occur in Figure 6-10: 3 individuals need to wait.
Now we can start to improve the model by adding the following business knowledge in the model.
(1) Part number in the PO (generate high competition).
(2) Part of the modified PO is less than the modifications.
(3) changes to the Price (the price) is not necessarily spread to an existing PO, PO modify the price depending upon what state.
When considering they have been delivered and archived PO, the third point is particularly evident. They show, of course, is the price at which to fill, rather than the current price.
Implement this model can ensure that the resulting PO fixed rules and procurement-related items, while the price of modified parts will not immediately affect the procurement of items referenced components. Rule involves a broader can be met by other means. For example, the system can purchase items listed for the user every day price expired, so users can decide whether to update or remove purchase items. But this must not remain fixed rules. By reducing reliance on Part of procurement items, avoid contention, and to better reflect the realities of the business. At the same time, strengthen the relationship between the PO and purchase items to ensure compliance with this important business rules.
AGGREGATE forced the business in line with their respective relationships between the PO and the actual purchase items. PO and create and delete purchase items are naturally linked, and create and delete Part of it is independent.
AGGREGATE divided into a range, in this range, each stage of the life cycle must meet certain fixed rules. REPOSITORY FACTORY modes and to be discussed next are operations performed on the AGGREGATE, they are converted to the complexity of the life cycle of a particular package together ......
Personal understanding: completely did not understand, it seems that the problem of processing resources modeling competition.
FACTORY
When an object is created or AGGREGATE to create a whole, if the work is to create complex, or too much exposed internal structure, it can be used for encapsulation FACTORY.
The main function of the object is reflected in its complex internal aspects and associated with Ge. We should have been the object of refining, until all its meaning or role in the interaction of unrelated content is completely removed so far. An object in its lifecycle to bear a lot of responsibility. If you let a complex object is responsible for its creation, the role overload will cause problems.
Automobile engine is a complex mechanical devices Ge, which consists of dozens of parts work together to perform their duties of the engine - the shaft is rotated. We can try to design a set of engine and let it crawl stuffed into a set of pistons and cylinders, spark plugs can also find the jack and put their own twist yourself into it. But the complexity of assembling such a machine may not be as reliable or efficient our common engine. Instead, we use other things to assemble the engine. Perhaps mechanic, or industrial robots. Whether it is a robot or human, in fact, than the two to be assembled engine complex. Assembly parts work and rotates the shaft work completely unrelated. Just need fitter when the production car does not need a robot or a mechanic when we drive. As the car assembly and the driver will never occur simultaneously, and therefore these two functions into a single mechanism is worthless. Similarly, the assembly work of complex composite objects is also preferably separated from the work object to be executed.
As the interface should implement the package of objects into the same (so that customers do not know the working mechanism of objects you can use the object function), FACTORY encapsulates the knowledge required to create complex objects or AGGREGATE. It provides an interface to reflect client objectives, as well as an abstract view of the object to be created.
Responsibility should be to create complex object instance and AGGREGATE transferred to a separate object, which in itself may not take responsibility in the domain model, but it is still part of the field of design. A complex assembly that encapsulates all operations interface, and this interface does not require the client to reference specific class object is instantiated. When creating AGGREGATE take it as a whole, and to ensure that it meets fixed rules.
FACTORY There are many design. [Gamma et al.1995] discussed in detail several specific purpose creation mode, comprising FACTORY METHOD (factory method), ABSTRACT FACTORY (abstract factory), and BUILDER (builder). The book studies the mode for the most complex object construction problems. The focus of this book is not in-depth discussion of design issues FACTORY, but to show the important position FACTORY - it is a key component of the field of design. FACTORY help ensure the proper use of MODEL-DRIVEN DESIGN forward along the right track.
Any good factories must meet two basic requirements
(1) is created for each atom method, but also to ensure that all objects created or fixed rules of AGGREGATE. FACTORY generated object to be in a consistent state. When generating ENTITY, this means creating a whole AGGREGATE meet all fixed rules, but you can add an optional element to the polymerization after the creation. When you create a constant VALUE OBJECT, which means that all properties must be initialized to the correct final state. If FACTORY its interface has received a request to create an object, but it can not properly create the object, then it should throw an exception, or other mechanisms to ensure that the error does not return a value through.
(2) FACTORY should be abstracted to the desired type, rather than specific classes to be created. [Gamma et al.1995] Advanced FACTORY mode of introduction to the topic
Personal understanding: I understand, creating an object if very complex (or initialized to assemble a lot of parameters, certain rules) you can use the factory pattern, technology developers should be well aware of the factory model, the business does not need to know what is the factory model.
Summary: did not understand, pay more attention to this part of the program objects and database design, there is the life-cycle model, a good look at design patterns and database design paradigm should be enough.