table of Contents
Domain Driven Design - the use of domain model - binding model and implement
Smart project team members spent several months of careful research and developed a detailed domain model (class diagram). However, research on class diagrams can not get my insight code and design of the application, it makes me feel more troubled. When developers start implementing the application, they soon discovered, although analysts eloquence, they still can not convert this into a complex relationship that can be stored, transaction integrity unit can be retrieved and has.
Since the model is "correct," This is the result after technical analysts and business experts before they get a lot of collaboration, developers come to this conclusion: not the object-based concept as the basis for design. So they began to be developed specifically for the program design. Their design does use some of the original class model and the name of the property for data storage, but this design is not based on any existing model on the basis of.
Although this project to establish a domain model, but if the model can not directly help the development of software that can be run, then this paper model what significance does it have?
Domain-driven design requirements model not only can guide the early analytical work, it should also be the basis for the design. This design approach has important implications for writing code. Less obvious point is: domain-driven design requires a different modeling methods
Personal understanding: built model can learn quickly the necessary knowledge, can not be converted into program code to achieve, in the end how? I do not understand, anyway, I feel good complex
MODEL-DRIVEN DESIGN
In strict accordance with the basic model to write code, the code can make better express the meaning of design, and the model and the actual system fit.
Those projects simply will not have the domain model, only to realize one after another function by writing code, they can not take advantage of the knowledge and communication to digest the first two chapters in question brings. If it involves complex area will make the project difficult.
On the other hand, many complex projects really try to use some form of the domain model, but did not closely linked to the preparation of the model code. These model projects designed early in the project can also do some exploratory work, but as the project progresses, these models project further away, or even misleading. All the energy spent on the model can not guarantee the correctness of programming, because the model and design is different.
Contact between the model and the programming may be corrupted in many cases, but this separation between the two is often intentional's. Many methods are designed to promote the use of completely divorced from model to programming, and often the two are developed by different persons. It is called a model, because it is the result of the analysis of business areas, it concept in the field of business organization, do not consider themselves entirely in the software system will play a role. Analysis model is only an instrument to understand, and realize that people think it is tantamount to a program linked to a muddy pond of clear water. It may only loosely maintain a correspondence between the programming and the subsequent analysis model. It did not consider the issue of programming when you create the analysis model, analysis model and therefore most likely not meet programming needs.
This analysis will have some knowledge of the digestive process, but after the start of encoding, if the developer had to re-design abstraction, much of domain knowledge will be discarded. In this way, we can not guarantee the analyst can retain or reproduce obtained and embedded in the model domain knowledge in new programming. At this step, to maintain the correspondence between the programming model and loosely connected very uneconomical.
Personal understanding: business model diagram drawn in the technician view, need to be translated into a process model diagram (flow chart), so there will certainly be different parts between the two models, there will be some areas of knowledge give up, that this correspondence between the two models need to maintain, it will increase the complexity.
Whatever the reason, the absence of the concept of design software, the software at best is a mechanized product - only to realize useful functions, but can not explain the reason for the operation.
If the entire program is not part of its core design or correspond to the domain model, then the model is of no value, the correctness of the software is also questionable. At the same time, overly complex correspondence between the model and the design function is also difficult to understand, the actual project, when the design changes can not maintain this relationship. If the analysis of serious differences between and design, then knowledge in the analysis and design activities acquired will not be shared with each other.
Personal understanding: above I did not understand, anyway, that is a flow chart of business models and technologies involved are very different, because of different ways of thinking, making it difficult to maintain correspondence.
MODEL-DRIVEN DESIGN (model-driven design) model and will no longer be separated from programming, but to seek a way to meet both the needs of a single model. Irrespective of purely technical issues, programming each object reflects the appropriate conceptual model described. This requires us to a higher standard to select the model, because it must satisfy two completely different goals.
There are many ways in the field of abstraction, there are many design can solve the problem of the application. Thus, the binding and programming model is feasible. But this can not be binding because of technical considerations undermine the analysis function, we can not accept that only reflects the concept of the field but abandoned the poor design software design principles. Model and design bindings need is able to play a good role in the analysis and design phase of the program model. If the model seems less practical for the realization of the program, we have to redesign it. And if the model can not faithfully describe areas of key concepts, it must also be redesigned. In this way, modeling and programming to combine into a unified iterative development process.
The domain model and programming closely linked to an absolute necessity, which also makes the selection of the most suitable model for the many alternative models, the addition of a selection criteria. It requires us to seriously consider, and often through the process repeatedly modified and reconstructed, but the model can be associated with design through this process.
To create a single model is able to grasp the main issues and help design the program and did not say so easy. We can not readily grasp a model designed to put it into use. Only model designed to facilitate practical implementation.
Personal understanding: modeling so hard, anyway, the business and technical thinking to abstract universal model, itself a learning costs, not everyone can achieve. Really do doubt the model is not the time not as a direct development to the altogether less engage in these virtual first Pakistani brain thing. The model is a foreigner love!
Modeling paradigms and tools support
To make MODEL-DRIVEN DESIGN play a role, we must strictly ensure consistency between the model and design under control. To achieve this strict consistency, must be supported by the use of software tools for modeling paradigms, it can create the corresponding conceptual model directly in the program.
The reason why the powerful object-oriented programming, because it is based on modeling paradigm, and provides for the implementation of the model structure. From the programmer's perspective, real objects in memory, they are interconnected with other objects, which are organized into classes, and to complete the corresponding messaging behavior. Many developers only benefit the object of technical ability - with its organizational code, the code only conceptual model with expression of the real breakthrough was manifested object design. Java and many other tools allows you to create a direct reflection of the relationship between the object and the concept of the object model.
I did not understand, simply ignored. Design is not achieved overnight. We need to repeatedly research knowledge, and continuously reconstruction model areas important concept to be refined into simple and clear model.
Why model is critical to the user
In theory, maybe you can show any kind of system users to view, regardless of the underlying how. But in fact, the underlying structure of the system ranging from misleading mismatch, while generating bug.
If the program is based on a design that reflects the fundamental problem of users and experts in the field of interest of the model, then compared with other design approach, the gist of this design can be more clearly presented to the user. Allow users to understand the model, they will have more opportunities to tap the potential of the software, the software also enables the behavior of reasonable and consistent.
Personal understanding: This theory says a lot, in fact, that if the model did a poor job, a direct result of doing things will come out of the complex and difficult to use, the user can not accept.
HANDS-ON MODELER
People always likened the software development industry. A corollary of this parable is: experienced engineers to do the design work, and low skill levels of the labor force is responsible for assembling products. This approach enables many projects in trouble, the reason is very simple - the software development is the design. Although the development has its own responsibilities to each member of the team, but the analysis, modeling, design and programming work excessive separation will MODEL-DRIVEN DESIGN adverse effects. I was responsible for coordinating the different application development team in a project to help develop the domain model can be driven programming. However, management believes modelers should only be responsible for modeling work, writing code is a waste of such skills, so they allowed me to write code or to discuss details and programmers.
Personal understanding: Now a lot of software engineering is divided process: research - requirements review - outline design - detailed design - System development - testing - on line - maintenance, are each responsible for their own modules do not you? Many Japanese outsourcing is designed to take the Japanese pseudo code and flowcharts, translated directly with the program. Is your understanding of a problem?
Start the project's progress fairly smoothly. I and experts in the field as well as the development team responsible for working together to digest domain knowledge and refine a nice core model. However, this model has never come in handy for two reasons.
Some intent First, the model is lost in its delivery process. Greatly affected the overall effect of these details by the details of the model is not always encountered in the UML diagram or general discussion. If I could roll up its sleeves and work together directly with the developer to provide some reference code and close technical support, then they may be able to understand abstract concepts and models developed accordingly.
The second reason is the model and its programming and technology influence each other, and I can not get this feedback directly. For example, the program implements found during an extremely low efficiency of the model on our technology platform, but after a few months, I was a little bit to get all the information on the subject. In fact, just a little change can solve this problem, but a few months later, change or not change is not important. Because developers have to write their own software can run - completely out of the design model, in those places still using the model, it is only treat it as pure data structure. Developers, regardless of good or bad to negate the model, but what can they do? They no longer willing to take risks and let stay in the ivory tower architects mercy.
And other projects, the project's initial environmental modelers tend not to participate in too many programs implementation. For most of the technology used in this project, I have a lot of practical experience. Before doing modeling work, I do not even have led a small development team in similar projects, so I'm very familiar with the project development process and programming environment. But if not let modelers involved in the program to achieve, I just have these experiences can not work effectively.
If the person writing the code think they do not need to be responsible for the model, or do not know how to make an application service model, then the model is and does not have any relevance. If developers do not realize it means to change the code to change the model, they reconstruct the program will not only enhance the role model, but will also weaken its effect. Similarly, if the modeler is not involved in the process of realization of the program, then the program implementation constraints there is no personal experience, if any, will soon forget. Two basic elements MODEL-DRIVEN DESIGN (ie model to support the effective implementation and abstracts of key areas of knowledge) has lost a final model will no longer practical. Finally, if the division blocked the collaboration between designers and developers so that they can not achieve MODEL-DRIVEN DESIGN convey all the details, so experienced designers can not pass their knowledge and technology to developers.
HANDS-ON MODELER (hands-modeler) does not mean that team members can not have their own professional role. Including Extreme Programming, including each of the agile process will assign roles to team members, other informal professional role will produce naturally. But if the modeling MODEL-DRIVEN DESIGN closely related to and implement these two processes are separated, problems can occur.
The effectiveness of the overall design of a few very sensitive factor - that is fine-grained design and implementation of the quality and consistency of decision-making. In MODEL-DRIVEN DESIGN, the expression of the model code, the code changes to change certain corresponding models. Programmer is modelers, whether or not they like it. So at the beginning of the project, it should allow the programmer to complete the outstanding modeling work.
Any person involved in modeling technology, no matter what the main responsibilities in the project that must take time to understand the code. Any person who edits the code you must learn to use the code to express model. Each developer must be involved in the discussion model to varying degrees, and keep in touch with experts in the field. People involved in different jobs must be a conscious contact with the code by UBIQUITOUS LANGUAGE people timely exchange of ideas on the model.
The modeling and programming process is completely separate is not feasible, but large-scale projects still need technical director to coordinate high-level design and modeling, and to help make the most difficult or most critical decisions.
Personal understanding: everyone should be a little modeling, even developers, but also to participate, even business people, should know a little more code. Everyone should have their own expertise, but also comprehensive development, understand the contents of the entire work process. Bottom line: you can not do it, but can not will not. Suddenly there is a demand or need a programmer to do the detailed design, but also can carry off this task. Purpose is not to allow a person to do more tasks, more responsibility as the software development process, but we know how to communicate after some modeling there are no obstacles, would understand each other.