. NET domain driven design-first taste (one: questions, patterns, principles, tools, processes, frameworks, practices)

. NET domain driven design-first taste (one: questions, patterns, principles, tools, processes, frameworks, practices)2013-04-07 17:35:27Tags:. NET DDD Driver Design original works, allow reprint, please be sure to use hyperlinks in the form of the original source of the article, author information and this statement. Otherwise, the legal liability will be investigated. http://wangqingpei557.blog.51cto.com/1009349/1173006

• 1.1. Questions
  • 1.1.1.UML How to use
  • 1.1.2. Domain Modeling
• 1.2. Mode
• 1.3. Principles
• 1.4. Tools
• 1.5. Process
• 1.6. Framework
• 1.7. Project Presentation

Recently in the study of ddd quite fruitful, so put together to share with you, common progress!

We have a very difficult and unavoidable problem when designing business systems "Business Extensibility", "Business Agility," "Object oriented", although we are proficient in design ideas, design patterns, design principles and so on how to design the flexibility of the system design theory, But we don't seem to have used them in the design and development of real business systems, why? Such a question would have been a long time ago for a friend with a desire to design a good system, but it cannot be solved because the design method we are using today is contrary to object-oriented design.

The long history of database-driven development makes it impossible for us to learn and combat from this environment. From the textbook to the Real Enterprise project development is to design the database and then the logical writing, most of the business logic is in the UI and database " stored procedures, custom functions ," the so-called three-tier architecture of the BLL layer is in fact the form of a fake, and did not play its rightful role.

Of course we are not masters, we are just ordinary programmers, we hope that there is a methodology to guide us in the actual system design. Before contacting DDD, I also have the same problem, we write a lot of development framework, components, plugins, services and so many too much like to improve the development efficiency of the function, dream of their own system can really like the book said to build their own system of bricks, we iittie giri ask ourselves really can do it? I sigh, hard;

I have always felt that complex system design for me really have no way to deal with, only by virtue of careful and familiar with the business, no correct theoretical guidance, the so-called Masters of the design of the idea of the book really help me, see do not know how to use. to this day I can finally feel that the mysterious design can indeed lead us through the recurrent system design. Of course, this road to the first contact with DDD friends will have a lot of problems, happen to be fortunate to contact DDD a bit of experience, but also through the analysis of a small system for DDD development work, so here to their recent study of the experience and doubts to share with peers, if there is no place please more guidance. [King Qingyue All rights reserved, reprint please give the signature]

1.1 "Questions

There are several key issues that need to be addressed before any new technology is adopted, and this is a necessary process for our programmers to consider using a new technology, which can solve problems and problems. DDD is good, but to apply it to your project requires a lot of time and effort to analyze its implementation process and the requirements of the project team. Of course, man-made factors and external environmental problems we do not consider here, after all, those are things we can not change, here only to discuss with our closely related issues.

1.1.1 "How to use UML

we all know what UML is doing, and it is a standard system modeling language, which makes it easy for us to analyze the system and cooperate with the team. Since it is a language its main function is to communicate, technician and analyze the human bridge. But so far I have not found that it really helped me with the system analysis and design, which has been mentioned in fact, the two development methodologies are actually the opposite, so lead to no integration, take the UML class diagram, we are the first design database and then to develop the object? Direct is the table driver, through a number of fast code generator interface and some common single-table CDUs code generation, there is no concept of object in the program, business logic throughout the UI layer [Figure 1.1]. UML Picture class diagram can not be displayed in the program, so it can not be popularized in most enterprises.

1.1 Figure

Hypothesis is a simple simulation of the basic function of consumer-to-consumer, through which we can easily understand the problem of our system development.

In the system structure, it is difficult for us to know the specific business logic of the system, let alone to ensure the extended performance of the system. Such a structure in the early stages of development there is no problem, but in the later maintenance work will be laborious, the final project code can not be done very good reading, it will not be very good stability maintenance. In particular, the business system, its requirements will become a lot of even abnormal, if maintained in this way, then the interface of the code will be more and more, and the BLL, Dal in the repetition of functional methods will be significantly more or the same function of the service layer different method parameters of the code will be more and more. In fact, in the end there is no art, let alone the project after the listing of products.

so does UML really play a role? Or are we really out of the UML? Of course not, but we do not use the relevant software design, development methodology. According to DDD, we are business-driven development, creating domain models first, then database design. in fact, only according to the development of DDD theory to ensure the maximum system scalability and business cleanliness, to ensure the virtuous cycle of the project. [King Qingyue All rights reserved, reprint please give the signature]

1.1.2 "Domain modeling

"Domain Modeling" is a very abstract and artistic word, it is a realm of software design art.

We often have access to object-oriented programming, object-oriented design books or topics, and we all have a unique perspective on it, but we have never used it as a truly systematic development. However, when writing the framework, we are able to carry out the object-oriented design, in order to ensure that the flexibility of the framework and even the greatest scalability of the most granular decomposition, abstraction, extraction, these in non-database system development is not a problem. The biggest problem, however, is that the object needs to be combined with the database, the life cycle of the object is persisted in the database, and the database is also alive. So the problem here is how to smooth over-persistence between object-oriented design and relational database design. This is the biggest problem of domain-driven development, and also a lot of development focus for the DDD framework.

We have seen the approximate structure of a database-driven system, assuming that we need to ensure maximum scalability of the function modules. When we write database-driven code, it is difficult to abstract the complex point of change, because it is a business model of anemia or there is no knowing where the change is. And not common developers can be found, of course, database-driven development can also be flexible design, development, but this is after all a high demand for developers, he needs to have a strong object-oriented design capabilities, without polluting the existing code in the case of the expansion of refactoring. At least my experience tells me it's hard, and there's no complete bigger picture at the demand stage, which can easily cause top-heaviness. It is also difficult to control the progress of the later system development because it is not possible to determine which interfaces exist for each functional module.

So we are still moving towards the bright Road, mastering DDD for system design and development.

Below we try to use the modeling approach to the function points in the general object-oriented design, as far as possible to extract the point of change.

"Simple use case"

Based on the basic functions we determine two sets of use cases, the first group is " customer Custom" initiated all actions, the second group is "admin Administrator", such as the distribution department, the order audit department and so on. This is purely to demonstrate that the functionality of modeling is not specifically project practice, so the functionality is straightforward.

1.2 Figure

After the customer first entered the platform must be the "registration" of the account, there will be a "logout", where the deregistration is not the meaning of the exit system, but the cancellation in the current platform of the use, with the sale of the user is a meaning.

(Of course, some people will feel that the cancellation is inappropriate, e-commerce platform should not have to write off, this is only the subjective design, everyone's ideas are different so can learn from each other, I think there is a positive logout function is very good, can let users use, in the end how to use our here is not analyzed. )

Become an official user after you can choose their favorite products to "place an order", the next order will enter the platform to run the management process, customers will receive the platform sent over the process information feedback. So here's a "SMS Management" use case, which will of course contain the sub-use cases of "delete information," "Read information," "Reply message."

(Of course, I can not analyze the detailed or problematic place, because I also recently contacted UML modeling so may be a bit unfamiliar with the UML interested friends can refer to relevant professional books. )

1.3 Figure

The background manager needs to carry on the "delivery" processing to the customer's order, the distribution link will involve "The customer information", "The Update order Status", "The Print distribution Information" Use case, to "Print the distribution Information"

The function needs to "send receiving information" to the user, informing the user that the goods have been issued. It also includes a generalization of the use case "inventory, delivery address", in the "Print distribution Information" function, you need to print out the information related to the distribution of goods.

(The UML Use case diagram here is actually to find all the function points of the system by vertical and horizontal way, vertical is all the functions of the system, the lateral is the external caller of the system.) ）

"Domain Model"

Based on the above use case we can basically capture the approximate system function, below we create a UML class diagram to describe the domain model.

The creation of the model is analyzed based on the use case diagram of the previous step, as long as the created model can satisfy all the functional points of the use case and a rough outline has been completed. There are hidden models that need constant refactoring to emerge gradually.

1.4 Figure

The approximate model has been created, which can only be modeled as a basic sketch, and there are several processes that have not gone through, such as repeated refactoring, discussing the accuracy of models with domain experts, communicating with DBAs, and so on, all of which are the whole scope of DDD.

With the domain model after we basically have a general business direction, the rest is the process of excellence, and constantly to analyze the deep business relationship.

"Scene sequence"

after we get the domain model, we need to do a basic validation of it, that is to see if the model meets all the functional requirements. The most common use is to walk through the scene with sequence diagrams, and to step through the validation of the domain model we create.

Because of the time relationship I do not give all the sequence diagram here, only the representative sequence of "distribution."

1.5 Figure

Because of the fear that the film is too large to give the key sequence flow, can express its meaning on the line.

This is the classic DDD call sequence, which is not very clear on the specific object above, and there is a special example behind it that does a thorough analysis. [King Qingyue All rights reserved, reprint please give the signature]

1.2 "mode

Compared to the pattern, we all know what it means, some general ideas, solutions and methods of thinking. Of course, there are many patterns in the DDD field for us to learn and use, in the requirements stage is to explain the behavior patterns in the analysis phase of the analysis mode, in the design phase has a design mode, in the implementation phase of the implementation mode, there are macro architectural patterns.

Then in the field modeling, some predecessors summed up the analysis model can be used for our reference.

1.2.1 "Four-color prototype mode

Four-color prototype mode is my first contact with the analysis mode, of course, it is also found that it is indeed very useful, so give the comrades to share.

The four-color prototype model helps us to identify the core model of the business, which means that the kernel model should have several more important features.

basically want to use UML use case diagram to find out the domain model needs name \ Verb method to find the approximate model, and then follow the domain model 1.1 points to refine and explore, so as to find the relevant entity model. But some entity models can be seen at a glance, such as the "user", "Order", and "message" in the example above can be defined as the entity type, which is the core domain model in the current small example.

Look at the structure of the four-color prototype pattern:

1.6 Figure

Compared with the four-color prototype model, we can easily find the kernel model in the model, obviously we are the core model against the above domain model.

1.7 Figure

In contrast to this model we will find that the product is actually the core entity, but we can quickly find that we ignore it, the commodity also exists in the state and some value types, such as whether the use of goods is not in stock, the detailed properties of the commodity is also the existence of independent value objects. Of course, this depends on the current project requirements. The design of the too paradigm will bring some problems, there are performance problems, there are development cost issues, which need to be discussed in detail in order to finalize, so the anti-paradigm design has emerged. [King Qingyue All rights reserved, reprint please give the signature]

This article from the "humble if foolish, thirst for knowledge" blog, please be sure to keep this source http://wangqingpei557.blog.51cto.com/1009349/1173006

. NET domain driven design-first taste (one: questions, patterns, principles, tools, processes, frameworks, practices)