Update blog:
—- explores the development and design of complex/super complex front-end services


Github updates:
GerryIsWarrior/design

I haven’t written a blog for 3 months since my last blog post, and I have a lot of inspiration and new ideas in my head. Busy, of course, but busy is not the reason, so forgive me. This time I gave myself a dead order, I must produce something, so, I can summarize the things in my recent development and slowly make a little more.

PS: This is a thinking reference article, rather boring, reading time of 30 minutes (including thinking and verification)

As a deep-rooted business, we started with a complex requirement THAT I encountered. Chestnuts are as follows (can first see the picture to have an eye addiction) :


The requirements list is as follows:

  1. There are 20 different types of activities, and each button has a different text
  2. Each activity has a different show and hide scheme based on the activity state (up to 3-4 fields, respectively controlled)
  3. Define the display mode of buttons based on different service status (disabled? Or can be used?
  4. Each button has a different function
  5. The same button also has different functions for different events (such as adjusting offers, referencing different components for different events)
  6. One button, same function, but request interface and parameter are also different (old data old interface, new data new interface)

General requirements:

This is a migration of incomplete entry project, details of all activities and docking operation, the stability of the business (business changes need change, such as the new migration activities need to increase the new operation) and iteration (move other old projects and docking up), need to take into account the more simple and easy to expand and agile operation, of course, the cost of maintenance and development also need to consider.

Higher requirements:

  1. View, simple and clean, all kinds of logical judgment is not messy
  2. Vm layer, avoid excessive tedious, code logic and categorization clear
  3. Lower coupling, looser control, and greater agility for later splitting and development
  4. Easy unified management, can be unified management

I believe you have seen the requirements and requirements, everyone according to their programmer development experience and design experience, everyone has a different solution. In fact, every solution is a way, but the implementation cost and design thinking in different perspectives are different. So, WHAT I want to share with you is also a perfect solution after my reflection, which is just for your reference.

What is a business?

It goes without saying that all code written by programmers serves the business. But I want to ask you a question first. What is business?

In my boss’s eyes, business is my way of making money. In a salesperson’s mind, the business is what I need to accomplish; In the product’s eyes, the business is what I want to accomplish… Everyone understands business differently, but has anyone ever considered what a business really is in the eyes of a front-end developer??

Here are the business I understand from the front end, as follows:


So, in my understanding, I divided the business written at the front end into the following six parts:

  • Business data: Responsible for obtaining business data
  • Business logic: Implements the rules defined by the product
  • Logical data: Logical data produced by a set of rules
  • View data: Convert logical data to view data (do not bind logic and view directly)
  • View display: Directly drives the view layer to display corresponding views through view data
  • View capabilities: Display the assembled requirements through views

In a simple business case, maybe I get the back-end data and go straight to the render view layer and then perfect the functionality. The cost and complexity of the development is not worth it. Therefore, this business methodology can be useful in complex business requirements as well as in a combination of dismantling and maintenance. Below, I’ll take the initial example and break down the six major pieces of design around the business.

Specific implementation steps:

1. In modern frameworks (vue, React, Angular), the core and most flexible way to handle view changes is to make the data of the driving view configurable, so the first step is to make the data configuration of our button requirements as follows:

Assemble all of the button’s data into an array, and then a subset of the array encapsulates a configuration object that assembles the button’s text, callback, disable, etc., into a template

2. First of all, in my requirement, there is only one interface for data acquisition, which is not complicated. Therefore, I did not divide and manage this part for business data acquisition.

A simple front-end data request that is needed for other dynamic data refreshes because of the interface change, so HERE I encapsulate the request into a single function that just gets the business data

3. For the final view presentation, we need a view data to drive it. Sometimes we will mount the data produced by our business rules directly onto the view data, and then drive the view directly from the data produced by our business logic. However, in my design, I do not recommend that view data = logical data. Because of this, there is a strong dependency between our view data and our logical data, and sometimes the logical data is just defined by the business, rather than the one best suited for rendering the view data. If the logic fails, or if the data in front of it (in plain English, fetching back-end interface data) fails, then the heavily dependent view will not only fail, but sometimes even crash directly. So I do a layer of data transformation each time between view data and logical data.

TempData to view data, here to deal with every business data, and then assign a value to view data, in processing, can undertake fault-tolerant processing of business data, no matter how changes in the business logic, or business data is how to change, in my view data level, even if you hang up and I can still drive to my view, Default value at best, and not directly down. To some extent, it increases the robustness of the code

4. When we look at our business logic from the above code, all our logic is unified to the right of the view data, such as the button logic we discussed, so for the whole page function, the business logic of my button and all global functions are coupled in only one place. This design, adhering to the idea of low coupling, not so strong desire to control, very loose, very comfortable.

The red box is the business logic of the button.

5. The following is the split button logic, from the design layout of software engineering, the logic is removed to the outermost layer, and other configuration files, enumeration files (personal feel convenient).

Create a logical repository in the project

6. Introduce business logic code and other unified management files where real business is used.

This introduces global unified management of enumeration values, button splitting logic, and logical adapters

7. Because of considering, our business activity itself, two major categories (goods stores and individual activities) + 7 small class (different) + channels of different activities (6), a total of more than 20 activities demand, so for activities and activity data to the generality of the unified process is bound to lead to logic chaos, data corruption, code chaos, All kinds of IFs and nested IFs and so on, so there’s a state machine that lists all the activities that exist.

In the state machine, activities are determined for type + channel. Each state to leaf node wraps the business logic corresponding to this activity, while business data common to this activity type is wrapped under the node of activity type.

8. We look at the button logic under each activity in detail. In the button logic, we do not know the function of each button, but we know the type of thing that the button is supposed to do. Then through the incoming business data, according to the business logic, output logical data.

Font is the text of the button, behavior is the behavior that the button needs to do, and data is some data that needs to be attached after the button is operated. Then, according to the business logic rules, output logical data under an activity for use by the view data

9. In this way, we can load different logic in different state machines according to different rules. For example, this state machine output code, I need button logic, I match the button logic, I need to match the image data shared by the entire activity, I directly load the state machine of the activity type.

Load the logic rules corresponding to the state machine so that we can completely split the logic.

10. Completely split button logic becomes a single dot, but this logic only defines the behavior required by the button, not the implementation of the specific behavior of the button. When I designed the specific implementation of the button, I took into account that all the implementation of the button were in one page, and some business data and view data were directly called to operate view changes and logical data changes. Therefore, I did not separate the implementation of the behavior in my project. Here is a list and implementation of the actions I have defined for the corresponding buttons:

Define the behavior required by the button logic directly in Vue’s Methods

11. After the service logic of the button is designed, reserve functional interfaces. Internal components define concrete implementations of behavior and open functional docking. Now you need an adapter to tie the definition and implementation together. This button adapter is to connect the logical data generated by the button with the concrete implementation to truly produce the logical data


Through the adapter, the definition and implementation are split separately. And then it connects to the logical data

12. Then bind the collected temporary view data to the real view data to render the view, so that we can get the complete view required by the business. The user can click the button to operate the function of the view, according to the attached data in the button split, to determine which button the user specifically to operate, what function of the button, and need to request different interface, interface data and so on

Data is attached data, and what fields defined in the data are used according to their own business requirements.

The overall design idea is as follows:


According to the design diagram of this idea, the complex requirements can be broken down and the business requirements can be solved accordingly:

20 activities, using the state machine to output the different button text displayed for each activity

  1. In a state machine, the hide and show buttons are used based on service data, including the disabled and available logic. Output logical data
  2. The buttons of each state machine define user behavior, which is implemented in the behavior implementation
  3. Determine the different functions a button implements in the state machine based on the behavior + additional data, including other differentiated schemes (such as requesting different interfaces)
  4. State machine + implements the separation of different data generated by interfaces, which is very suitable for business instability and iterative compatibility. Loose control and low coupling state, for the addition and removal of activities, the removal and addition of functional buttons, as well as the increase of button function implementation, more convenient development and operation
  5. Because the View is configurable, all states are implemented in the business logic layer, directly generating logical data to drive the view data, so the View layer is clean and clean
  6. The state machine manages service logic and behavior in a unified manner, and implements interface management in a unified manner

This is just a business methodology that I have recently developed in my business development career. It is an exploration of complex and ultra-complex businesses. The above is just an example of a requirement that you can refer to in your own case. Grasp specific business characteristics, such as initial design scale, continuous growth scale, and future development scale (whether to split), etc.

Reference ideas:

1. Individual architecture and microservice architecture

A) The application of monolithic Architecture, in which the code of each component exists as a monolithic whole, the components cooperate with each other and share memory and resources.

B) Microservice Architecture is composed of many independent small applications, each of which has its own memory space and is expanded independently of other applications.

2. Browser event design idea

A) Event idea: Browser events are usually triggered by the user and then triggered by the developer’s implementation. As a result, the design of the browser itself does not know how the user actually implements it. So, browser events are designed to define a behavior (click or otherwise) in the browser, and then adapt and assemble the implementation of the behavior through an adapter, the method that registers the event

3. Process management

A) Process-based management refers to a management method that takes process as the main line. Front-end from data acquisition to the final display of view functions, including various business logic and view rendering in the middle, are a series of flow out of the results. So, and the split can also be split based on the process in these child nodes as a key point.

4. Agile development thinking

A) Agile development takes the evolution of users’ needs as the core and adopts an iterative and step-by-step approach to software development. Agile, the purpose of its existence is to evaluate and break down its own projects according to local conditions. Similar to this methodology, individuals and projects evaluate how to break it down, rather than pulling it all together.

The above is just a set of ideas and plans summarized in the process of my deep cultivation of business, for your reference only. And this methodology may not be perfect, so we can discuss it together and further discuss it.