Again, from here on out, we won’t be talking about development technology. Again, technology offers possibilities, and now we’re talking about strategies and ideas

abstract

Abstract is the process of extracting common and essential features from numerous things and abandoning their non-essential features

The most common example of abstract thinking is language

Will a real cow fall from the sky when we say ‘cow’? Don’t!

“A white horse is not a horse, is it?” Gong asked. “Neither the white horse nor the horse will come down from the sky!

Because these concepts only exist in our brains, our brains don’t store complete information about a horse or a cow, only their characteristics and behaviors

This is not object oriented (although it is often used as an example of object oriented), this is more essential than object oriented, this is “abstract formal system”.

The process of modeling through language communication, through tools like UML, essentially translates things in the real world into things in the world of thought (abstractions), and then we collaborate extensively through language and related tools

The job of the programmer is to reduce the abstract concept to the current of the real hardware. Yes, this is the job of translation!

Since it is translation, technical implementation is only a small part of our work. For example, if you are an English-Chinese interpreter, the Requirement of Chinese level is not as high as that of English level

Similarly, the level of business modeling and algorithmic/data structure required by programmers is much higher than the level of capability of the specific technology platform, which is only a minor detail (this idea is also the direct origin of microservices).

Yes, all that if else, for range, async await and even CH ->, ch <- is not a programmer’s job, analysis is

Therefore, concepts that are widespread in abstract formal systems are the ones we should study most, such as:

Abstract thinking stage: induction -> deduction -> deduction

  • Induction is the formal system creation process, class, monad function

  • Deductive is the process of creating relationships for formal systems, design patterns, types, and even event storms, test drives

  • Deduction, that is, on the basis of this system, in the absence of reality to provide the basis for prediction, this part is the development of higher-order application, such as knapsack problem, Bayesian prediction, artificial intelligence and other algorithm problems

Among them, development platform infrastructure and development paradigm determine the induction process

Yes, there are two main types of formal system at present, Turing object-oriented, Lamda calculus function, the former is the abstraction of ideas, the latter is the abstraction of change, which is called in design mode: construction model

And deduction is the ultimate abstract thinking, mathematics and algorithms dominate the field, beyond the scope of the current discussion

Deduction, let’s first figure out what kind of relationship there is between the concepts that come back:

Dependency, association, aggregation, composition

Dependencies: Reference call relationships, in the form of function parameters, import, and so on

Relational relationships: also known as strong dependencies, represented by member variables, maps, etc

One-way link

Bidirectional association

Its associated

Multidimensional association

The difference between an association and a dependency is if I can get rid of, say, import, I can get rid of a function parameter, I can get rid of a function parameter, but if it’s an association, the arrow can’t get rid of the other side

A good example is that if you just give a girl a gift (dependency), she won’t necessarily become boyfriend/girlfriend with you (correlation).

Aggregation relation: Set entity relation, also known as strong correlation relation, that is, a one-to-many unequal relation is formed between several associated entities, such as array and array element, object and member variable

Composition relationship: The whole part relationship, also known as strong aggregation relationship, requires the whole to be responsible for the creation and destruction of the part, the whole can fully control the part (public interface), such as member objects, monad, etc

Of course, there is generalization, that is, strong composition. Entities have ancestral state + behavior by default, and entities can access ancestors (protect interface). However, this level of relationship is completely unnecessary and is a mental obsession

In combination, the control direction is from whole to part, namely the members during initialization, don’t have access to initialize its instances (child components don’t have access to the parent component data, call the behavior of the parent), at this time, if you provide a whole instance references for instance, the equivalent of a dependency arrow pointing to the instance, then, The child instance can also invoke the behavior and state of the parent instance, a practice called inversion of control

// Function props inversion of control

const [a,setA] = useState()
// JSX is actually a function that passes a reference to setA to Child
// The parent component controls the life cycle of the Child, that is, the parent and Child are composed
// But because of the inversion of control for props, the Child can indirectly control the logic of the parent component
return <Child setA = {setA}/>
Copy the code

Note that the essence of inversion of control is to append parent instance logic to a child instance, requiring careful handling of local and external logic. This part of the scheme is called “domain events”, which we’ll talk about later

The logic of the relationship, regardless of the specific technology being developed, is that any platform, any technology, even product design, must follow this standard

From the above analysis, we can see that associations and references are too micro. The basic structure of application development is to use aggregation and composition in collocation

How do you put it together?

Aggregate out, combine in!

Why is that? Because aggregation is loosely coupled, it is easy to divide modules and communicate between modules, while composition is strongly coupled, which is easy to realize specific function points

This is high inside low even

A lot of people don’t get used to useContext, which leads to a lot of problems in implementing DDD, and a lot of mental burden, because there is no distinction between aggregation and composition, which doesn’t occur in the object-oriented paradigm (because composition is naturally a class).

For example, the following is a composition relationship (control initialization and destruction, i.e., no whole, no parts)

/ / hooks
function useOverall(){
   const partial = usePartial()
   const partial2 = usePartial2()
   const partial3 = usePartial3()
} 
/ / component
function Overall(){
  return <>{/* This inversion of control is called combined inversion of control */}<Partial onChange={xxx}/>
     <Partial/>
     <Partial/>
  </>
}
Copy the code

Yeah, we don’t useContext, because context is loosely coupled to useContext, and the initialization of subinstances is not controlled by the parent domain. In other words, we say context is inversion of control, specifically aggregate inversion of control, we say props, The higher order component is inversion of control, specifically the combination inversion of control

// aggregate hooks, loosely coupled, which do not control the initialization of subdomains
const token = createContext()
function useAggregation(){
   // ...
}
Copy the code

Because of the low coupling nature of aggregation, we prefer aggregation modeling when we talk about business, which means that by default all macro relationships are aggregation relationships

Between aggregations, a domain module can be formed according to functions, domains, and features. The root of all domains is called the aggregation root

Why the concept of domain modules? After all, the so-called function, domain, feature description, is too general, what is a clearer standard?

A unified language

Yes, the unified language, and this is the domain module demarcation standard

In our daily communication, there is a context by default, and the same word in different contexts has different meanings!

This is the common knowledge that we are not aware of, that is, every abstract concept has only its corresponding scope of application, and every language’s vocabulary has a series of generalization changes such as synonyms and professional nouns

For example, “orders” placed by users and “orders” placed by warehousing and logistics are completely different concepts.

Don’t realize that these are two concepts? So we’ll just have to wait until we get there to see the difference?

This language-dependent context, known as a module’s bounded context, is the sole criterion for module division

This section will not be covered because it is the subject of business-oriented development architecture, which will be covered later

The top-down

Of course, the nature of this development approach is’ analysis and then development ‘, requiring professional product managers or business experts to complete the construction of the entire system in the abstract test, so that the system will be very stable and efficient, at the same time, the aggregation of loose coupling nature can also be used to the extreme, such as microservices

However, if you work with non-professional product managers, or lack business experts, and develop without clear requirements, this architectural approach is not much different from normal development in terms of efficiency

However, it is impossible for people to create something they do not understand, and it is impossible to start the development work without analyzing the needs. Just like you, as an English-Chinese interpreter, the speakers do not speak English. How can you do the translation work?

You can wait for the opportunity from the bottom up, but there is no application in the world that libraries assemble themselves, there must be a top-down process, and this one cannot escape

A lot of people say layered solutions like Redux and MVC can start development right away, but what about logic? It is impossible for an application not to include business logic, and once business logic is included, the bad smell of these solutions becomes apparent, such as iterative, asynchronous initialization difficulties caused by loose coupling without aggregation (hierarchical solution is composite suite composition, i.e. global initialization, business-oriented solution is aggregate suite composition).

Now that we know the theoretical basis of BUSINESS-oriented development in the abstract deductive phase, we can discuss how to practice business-oriented development