So far, in order to solve the problem of improving the efficiency of the front-end development, the research and development students have derived a variety of construction mode, the core idea is: the multiple and repeated work is smoothen as far as possible, only for the customization needs to develop. Here we share a new model of building a website – building a system by building multiple domain models.

Existing scheme 1: page end building station.

This scheme is the approach of many active sites. Through a large number of front-end common components, in response to the needs of activities, through these components bottled, assembled into the site, this way is a good solution to the construction of pure front-end site. (Figure 1.1)

Figure 1.1

This scheme has a major limitation, it only serves “the page end is changeable, the back end is relatively fixed” scenarios, and is widely used in the “activity promotion page build” scenarios. However, for the changeable business requirements of the back-end, it is still necessary to customize the development of the back-end.

Existing scheme two: Serverless cloud function was born

Programmers are always lazy. Since the back-end capability of scheme 1 is relatively weak, the idea of Serverless cloud function was born immediately, and began to be gradually implemented in various business scenarios in 18-19. Through the construction of the station system and the cloud function, it can quickly respond to and deliver the demand

This solution solves almost 80% of common operational requirements:

  1. Station system through model -> view mode, according to the DB table directly mapped into the use of the site.
  2. Various event hooks are also provided for various customization logic.
  3. Through the cloud function system, all kinds of business logic can be completed online.

Limitations: Not suitable for the remaining 20% of the more domain-specific needs. Here we use touch system as an example, because touch system needs to describe complex goods, need to describe various touch rules, and have various offline logic.

In the face of high degree of customization, this kind of scheme fails to achieve substantial improvement.

Scheme 3: “Domain modeling” station construction scheme

Taking the back touch system as an example, we can abstract out three types of “people – goods – field” for the field of touch. All the touch systems are: push specific goods to specific people based on specific scenes. Therefore, we can derive the following three things to do:

  1. Reusability of precipitation system.
  2. Precipitation business reusable capability.
  3. Supports flexible and customized site construction.

Operator services – Reusable system capabilities

In the realm of touch, the smallest granularity is “operator” (other systems need to be abstracted separately), which is the smallest unit describing “people and goods yard”. It is the smallest system granularity for systems in the realm of touch.

Each operator is a vertical structure, consisting of front-end components, server logic, offline logic, data structure, storage scenarios. Each operator is not a simple front-end component, and it is understandable that it is a microservice that is smaller than a microservice. Through the assembly of each operator, the system can be assembled and delivered to customers.

At the same time, customers have various customization requirements, which are addressed through page hooks, event hooks, and server-side hooks.

Domain model – Reusable business capabilities

Operator service already has the ability to set up a website, but such improvement is not enough, because in the actual situation of customers, customers with the same business demands have the same 80% business capabilities, and only 20% of the customized parts (such as mobile phone and wifi all need message push, The skills they need are 80% the same). We need to achieve extreme efficiency, we need to precipitate this 80% of the repeatability. This is where the concept of a domain model comes in.

The domain model describes a common business capability, such as message push, cloud command, in-terminal touch, dynamic information, etc. It specifies which operator services are required in a business capability and how they are assembled.

The customer needs to push specific message content (goods) based on specific events (field) and specific business conditions (field) to the designated GUID crowd (people), which will be displayed in the form of notification bar on the client end. Based on this requirement, we can abstract a business capability called “message push” and express it through the domain model. Our goods operator respectively from the repository “message content operator”, to be obtained from the scene to calculate character inside collect “trigger point operator”, “operator” business conditions, from the crowd operator repository, quashing directional operator “crowd” ways that slice of parallel assembly, and for mig operator is a vertical structure, therefore, layered and see, all operators after assembled, It describes the UI layer, service layer, offline layer, and storage layer of the entire business. Through the model parser, the system shown on the right is generated. The same model can generate multiple systems repeatedly, so that we can achieve the ultimate improvement in the face of customers with the same business demands.

With the operator, the r & D students know what the system can support. With the domain model, business students know what we can sell. It can be said that only with the domain model can the productization of the project become operational.

Object – oriented web – balancing generality and customization

At this point we can precipitate 80% of the business common capability through the domain model, and the remaining 20% we refer to the design pattern of the aspect object as the site building mechanism. I believe that we are familiar with object-oriented, it has three characteristics: encapsulation, inheritance, polymorphism.

We just pushed analogy example of a domain model is compared to a class, model encapsulated within quite a good operator and attributes of a class, and the process of generating system can be instantiated, the process of system in addition to the operator can inherit model, can also according to customer demand customized dynamic increase or decrease in operator, and mentioned each operator has a variety of hooks, This means that operators are reloadable, page hooks support skin, events support custom interactions, and back-end hooks support writing custom logic.

In this way, the dynamic addition and subtraction operator, plus the operator can be overloaded, can effectively cope with the remaining 20% of customer customization requirements.

Overall solution: Operator service + domain model + object oriented

  1. The operator services precipitate reusable system capabilities, landing on the operator library. (2)
  2. The domain model precipitates reusable business capabilities into the domain model library. (2)
  3. Through the object-oriented pattern, as the system generation mechanism. (flexible)

Welcome to exchange ~~~~~~~

\