Shulou(Shulou.com)06/01 Report--

This article mainly explains "the architecture specification of web design based on domain analysis". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the architecture specification of web design based on domain analysis".

The world after the isolation of reading and writing

Based on the idea of read-write separation mentioned above, we can see clearly that the above situation can be seen:

Query business, from the entry layer (such as Controller), call Finder, and Finder call Repository (specific implementation such as Hiberante,Mybatis, etc.). From this line, we do not have to consider how the additions, deletions and modifications of the system are done, just as they are in a completely different space, do not interfere with each other, do not affect each other, or even never see each other. To some extent, the effect that this architecture pursues is a sense of beauty.

So, next, we focus on the addition, deletion and modification part, that is, the command operation begins to modify the system in a down-to-earth manner.

First of all, let's raise our horizons a little bit and take a look at the products of the whole project.

Business Soul-State Diagram

Except for a few very flat pure technical service projects (such as AI recognition, text analysis, etc.), most other enterprise projects have their core business logic, and these logics are often withdrawn from the core domain concepts, mapping from a simple and rough point of view to design and development, that is, class-like.

E-commerce system, the core areas are at least [goods], [orders], [users], [logistics], etc.

SNS social platform, at least [users], [blog posts / posts], [private messages], [notifications], etc.

Purchase, sale and storage system, at least [account], [role / permission], [commodity], [customer / supplier], etc.

Online education platform, at least [users], [courses], [orders], etc.

Among them, there are also primary and secondary, you can look back at the projects you have developed. But classes with stateful fields are likely to be one of the core areas of the entire project. In fact, it is easy to understand, because it has a process, because it needs to be changed by various operations to change its state, so it is likely to run through some key business logic in this project, such as the e-commerce system.

[order] there must be a status, from [to be paid]-[paid]-[in delivery]-[received], and even [cancelled], [refund], [refund failure], [refund success], brain compensation, you'll know how many complex business processes will be generated.

[user] generally speaking, there will be states, such as [normal] and [frozen], but it is conceivable that if a system does not have such permission and security requirements, [user] may not have a state. then naturally, there will be no corresponding action to modify it, but only creation.

So, if I were asked to select the most important UML diagram in the early design phase of these systems, I would choose the state diagram. Here is the core order status diagram in the whole system.

As we can see, to grasp the state changes in a core area, we can naturally sum up a large part of the functional requirements of the system. We can see here that all the actions triggered by these arrows are actually commands, and they will actually land on the additions, deletions and modifications in various related fields.

Of course, this is still a coarse-grained representation, which cannot be developed immediately based on this alone, because even the functions represented by each arrow can write a complete or even complex use case. But at least this is a very clear guide.

The World of anemia models

Almost all of the Spring systems we use at present are anemia models, that is to say, in the real entity class, there are only Get and Set methods with various attributes. And if we want to do an operation, the order is cancelled, then what is the most common practice?

/ / A large and comprehensive order service class public class OrderService {public void cancelOrder (Long orderId) {Order order = orderRepository.getById (orderId); order.setStatus (OrderStatus.CANCELLED); / / omitted, the operation of other attributes.}} / / then call orderService.cancelOrder (10086) in the upper layer (such as the Controller layer)

This is a very popular practice in the industry at present, and it is also a natural practice formed by Spring's IOC mechanism-as stateless as possible. In this way, the criteria for judging code changes during business iterations are relatively simple, just put them in Service, and then entity objects only need GetSet, which is simple and easy to use. It is this feature that makes this coding style popular.

The above words do not have any derogatory meaning, because anything, existence is reasonable, almost all the company projects I have experienced are done in this way, there is no big problem in cooperation, and the business is doing well.

Then why do I want to make some changes?

The World of physical Entity

Because I think we need to re-examine the physical Entity.

Why should an entity have a primary key? Since there is no primary key, how do we know which data to query / modify?

There is no problem with this answer, but there is a deeper meaning in this sentence.

This entity is a real thing (yes, even if it is invisible, it still exists) and is "stored / persisted" in a storage medium, such as a database, in a form.

When we need to operate on an entity, we need to "load / read / get" it in a way, just like when you pick up a courier, the courier takes it out of the package according to the number you provided. exactly the same.

What if I take it out? Then, of course, it is necessary to operate it. Yes, this operation is to operate on the entity we have found, rather than anything else.

So, from "take" to "operate", everything makes sense, so the practice of domain-driven design, or hyperemia model, will be like this:

/ / Application layer entry class. Take Controller as an example: public class OrderController {@ PostMapping ("/ cancel") @ Transactional public ActionResponse cancelOrder (@ RequestBody CancelOrderRequest request) {/ / fetch: locate the entity we want to operate Order order = orderRepository.getById (request.getOrderId ()) according to the identifier; / / Operation: yes, that's right, that's right, I'm talking about you, operating on you, no one else! Order.cancel (); / / returns the result return ActionResponse.ok ();}} / / the real business logic is @ Entitypublic class Order {private OrderStatus status; private String customerName; / / in the Order entity. Public void cancel () {/ / change status status = OrderStatus.CANCELLED; / / some other attribute changes, slightly}}

Well, there's still a lot to explore:

We have opened Transactional directly in Controller, which may seem a little unconventional, but I personally think there is nothing wrong with it, except that we are not used to it. When you think about it, it is just a component of Spring.

So if you use a JDBC framework such as Hibernate, you don't have to do extra save operations, which is a better way to extract the idea of domain design, because at this time, the order is a real entity that we have found out, and the changes to it are automatically mapped to the underlying persistence, which is natural and inevitable.

The place where it is most likely to cause a slot is order.cancel (), the essence of the hyperemia model, which locates behavior to an entity class rather than throwing it directly into the OrderService.

There has always been a very "wonderful" saying in the industry. I once longed for it very much, that is, "Let the code become a poem". In other words, since we pursue readability, we should try our best to make the code have a "subject-predicate-object" feeling as much as possible. Take the above "cancellation order" as an example, do we think:

The good end of the order is there, and it can't do anything to itself, so it should be "someone else" to operate on him: OrderService.cancel (orderId); so-and-so cancels the order Perfect! If you read in this way, it will be very smooth and readable!

I used to be loyal to this style, and Spring's widely circulated stateless architecture model carried it forward. It's just that now, after experiencing the development requirements of more and more complex businesses and long transactions, I feel more and more that this is still a bit hard.

If you have to read smoothly, it should be someOperator.cancel (orderId), that is, some operator canceled the order, not OrderService. Everyone knows that OrderService is just a large collection of stateless code, a cold code. But obviously someOperator.cancel (orderId) this kind of practice is also more impossible, the reason does not need to explain too much.

Order.cancel (), there are only two parts, {who is the target of the operation}. {what has been done}, clear and concise. I believe that most people's reading habits also go from left to right, so the first target swept down the line of sight must be the leftmost executive object, that is, order, then it can be clear at the first time who this behavior is happening to, and if it is orderService.cancel (orderId), virtually, orderService is a huge noise that occupies the most powerful position of sight-- because it doesn't have any business significance, what you want to see. Instead, it is the later methods and parameters, which can quickly get sleepy and lose your way when reading hundreds or even hundreds of lines of compound long business.

Thank you for your reading, the above is the content of "domain-based analysis of the architecture specification of web design". After the study of this article, I believe you have a deeper understanding of the architecture specification of web design based on domain analysis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.