The way of continuous reconstruction of complex business of large web site--The practice of whole field modeling

People introduction:

Jack chen--, the chief architecture architect of the pet store, has extensive experience in software design and modeling, but is skeptical about new things.

Wang--"Pet Shop" general manager, after studying abroad from the United States to create a "pet Shop" website. The easy way to succeed has made him a stubborn and bossy style.

Spark--jack Chen's university classmate, a senior consultant at a business software company. Recent enthusiasm for promoting "domain-driven design" best practices.

Primer

Like some of the magical kid stories that you've heard about, a couple of turtles who swam back from the Atlantic found a great idea--to run online stores on the internet to sell pets. Luckily, they found investors and developed very well. But over time, the "perfect" technology structure became overwhelmed with more and more baskets of demand. Jack Chen, the company's chief architect, has been suffering from insomnia for several days by "trivial" demands.

Jack Chen, who was excited by the king in one by one, shouted at the office, and was immediately shocked by the idea of the king throwing it out.

"I have a very cool idea that we can provide online booking services for pet hospitals online." And not just sell them, do you know what that means? This is an annual output value of tens of billions of market!!! ”。

"But Wang, our system can not support this kind of in-kind service booking sales, it may have a huge impact on our original website, we need three months to conduct a full evaluation of the business ..."

Jack Chen was immediately interrupted by the aggressive king, "three-month assessment?" I need to be online this new business within two months. Our investors are very much in favor of my idea, and ask us to immediately put the project online, it may help us improve the IPO price next year. Do you understand? Do IT asap! ”

Evaluation

"Well, maybe this damn King Fatso is right. Our mix of technology and business is also the time to tidy up. "Jack Chen, who has been complaining for half an hour, is finally back to normal, and I think I should see what we're looking at, and what we need to do to support the damned" online service for our Pet hospital. So Jack Chen on the whiteboard quickly drew the following case diagram.

Fig. 1 Total usecase of the original pet store

In order to support the "online booking" of this particular product, it will affect most use cases, as listed below:

product information needs to increase the "appointment time" This attribute, the customer will place the order as a key element to identify an appointment. "Online booking" is a virtual product, it does not need to really need to check the goods and packaging shipments, if it does, I would be too stupid. Each pet hospital can only accept a certain number of appointments per day, and in this sense it has a similar concept of inventory with physical goods. But how do I express them? The most lethal thing is: do I really have to turn all these affected use case to support the virtual goods business? How could I have done this refactoring in 2 months? Silver Bullet

The lifeless Jack Chen wandered around the door of Wang's office, still without the courage to greet the storm-like Chinese-English bilingual version of the insult. "Maybe things have changed, and I seem to have heard of a silver bullet that can solve the problem of this system reconfiguration," he said. "Damn, who gave spark to me?" Field-driven design mat under the monitor, he's been preaching to me the magical changes that the book brings to his project, maybe I can try it too.

"Well, Spark, I admit that the book you recommended was great, and you made a good point," he said. I read it, understand and some concepts-for example: Domain segmentation, Entity, Service, Value Object ..., but I'm confused about how to do it. Can you directly share the best practices you get from refactoring projects directly to me? Otherwise, Monday Wang fat will not let go of the answer to my! ”。 After reading this book, Jack Chen finds it very rewarding, but he doesn't know how to start, and calling the pioneer of field modeling spark may be the quickest way to solve the problem.

"What, the question is a long story?" It doesn't matter, I already in your doorway, you and I slowly say, Jack Chen with Starbucks Coffee + KFC family barrel + Long duck neck + a flattering smile appeared in the spark door.

Sermon

Spark, after hearing Jack Chen's description of the status quo and needs, he lamely to say, "This is simple, and all you need to do now is to do something like this:"

the domain division of your system with a large scale structure to find out the domain of this requirement impact and to establish a technical framework for your company's domain-driven design refactoring the design and coding of various fields according to the need of urgency

Here's what we do in this order:

I. Overview Area Division

Jack Chen immediately repeated his previous use case, and then looked at spark with hope for approval. "Your mistake is too much about the case or the identity of the operator, and the division of the domain is not based on function or role, it is generally the case that we are going to assign a higher degree of use to a context." Try to make the domain more closed and have the same business language environment. For example, based on your use case diagram, I'll draw the following fields.

Figure 2 Pet shop Area channel Map

A channel diagram is a very useful tool for modeling business domain, and it can express the function of execution sequence and fragmentation at the same time.

Ii. identify affected areas and interfaces

From the field point of view, only the external interface of the goods will affect all areas, the need to establish the commodity domain (Productdomain) and read the Commodity Information Service Interface (Getproductservice) for refactoring.

, the use case, identified in green in Figure 2, is part of the need for code refactoring to support the "online booking" of virtual goods. This part of the work if the duration is relatively tight, you can give priority to use the mode of the code refactoring, which can also be easier to use the domain-driven design method to refactor again.

Iii. establishing a technical framework

This is not much mentioned in the book "Domain Driven Design". This needs to be combined with the original technical framework of your company to build a domain-driven technical framework by minimizing the cost-maximizing benefits of transformation. Here is a widely used domain-driven technology framework that adds more personality elements to your company's own framework.

Fig. 3 Field Driven design reference technology frame diagram

The elements of this framework are basically found in the book "Domain-driven design", but there is a need to explain my personal understanding of how to build this framework:

Domain external (page, AJAX, ESB invocation) only exposes Domain Services, all other domain classes are closed in packets, externally invisible. The introduction of the basic Warehouse, the basic warehouse is an abstract warehouse, it encapsulates a large number of common tool methods, business object Lifecycle Maintenance (entity or map, DAO calls), external interface calls. Reduces unnecessary duplication of code and complexity in the business warehouse. A business warehouse is a subclass of an inherited base warehouse. Infrastructure references, the infrastructure is used to host references to non-domain calls, and we tend to use domain-driven design to start with an old system refactoring. It is not possible to require all the business subsystems to invoke each other through domain service, when we can encapsulate the call into the business methods of the business warehouse by infrastructure gracefully.

Iv. reconstruction of the design and coding of affected areas

Fig. 4 Product detail Page class diagram after refactoring

Spark The example of the use case of the product detail page to illustrate the domain-driven design of the refactoring class diagram:

increases the behavior table productext the extended information used to store the goods, such as booking time, and booking a hospital. and establish one by one corresponding entity entity for the table. The base warehouse repository encapsulates operations on entities through DAO in infrastructure, such as Create (), update (), delete (), FindByID (), Findlist () The commodity business Warehouse Productrepository expands the base warehouse, the client program can use ProductID as the parameter, through Productvo.getproduct () method obtains the business realization of the commodity detail information, Because the public method of the business warehouse returns the value Object externally, it does not directly expose the entity type to the client. The Getproductservice service provides services via the Invoke () service method External (Commodity detail page) that invokes the business methods in the business warehouse and normalizes the interfaces. The transaction is configured on the Domainservice Invoke () method, that is, transaction control is controlled by the granularity of the use case. Epilogue

With the help of Spark, Jack Chen managed to get out of the trouble. Now he is actively pursuing his own domain-driven design framework in the company, and their company's Web site is rapidly iterating over the speed of refactoring every three weeks. Like Spark, he became a field-driven preacher.

Source: InfoQ