The idea of application architecture based on routing mechanism design

Reprint please indicate the source: Wang 亟亟 's way of Daniel

Nearly one months have not been issued, more recent things. Various kinds of meeting, write various plans, solve various problems, as well as the internal recruitment of the team of those things (every day the mailbox a variety of a dazzling)

Amway: My git will move content to git book and so on, so the guys who are interested in what I'm writing can follow my git to get the latest content!

Understanding of the architecture

Recently chatted a lot of small price from high to low of all kinds of have (here just for example, without any derogatory meaning)
A mention of the structure of the open mouth to MVC MVP MVVM and so on, and so on, if the CV is written with a large project architecture experience and the high price I generally default such a guy is not too available (first look, don't worry about the explanation), or your previous project "not big enough."

If the asking price is not very high, the experience is not very rich in writing, then I can understand.

Why is this "default"?

1. too General
   MVC that set from the writing of the Web period has been used so far, you grab a write Java Web can also give you a well-reasoned, paper-based no practical significance
2. Lack of practicality
   Each "heavyweight" project has different implementation methods, simple to take a few English words hard set is really reasonable, really suitable for their own application scenario
3. Knowledge Point Lag
   From the domestic Android/ios hot (Modular) Tide (15) After the emergence of a variety of content based on subcontracting, plug-in and so on, and expect a set of architecture to eat dead that is impossible.

Simple Component Design

The common attributes of the code extracted into a variety of basic libraries, the individual functions encapsulated into the library package, different services through the sub-structure divided into different module, each person in the group to develop their own module.

Simple subcontracting of pure business and non-business modules and some "just needed" code makes the relationship between libraries and libraries seem perfect.
The small partners who write each module can do it each, without any overlap.

So one day, there was a scene that could not be described.
(just to cite examples)
Until one day the product says that we want to integrate TalkingData, we want the UI library of the individual controls to do the burying point!

So what?

A small partner of the UI library to rely on a third-party statistical library to write the buried business inside

Also, the details of the UI component I want to calculate (you do not reasonable unreasonable, the product is said to calculate, we will simulate this is a must do business)

The UI library has to rely on the tool library, and then this architecture diagram becomes

This is just a round of iterations, followed by a variety of non-descriptive and complex poses, resulting in a mess of your project, maintainability and as bad as all the code in a bag.

Based on "Routing Architecture Design"

After a redesign, it's roughly long.

Because the base function library is really a library of highly dependent possibilities, so we let him rely on the "Routing" library.
All of the child packages, including the master project, are dependent on the library, and the base Function library relies on the tool library and the routing library
The meaning of the tool library is not said, there is a large probability of invoking the tool class throughout the app, whether it's a master project or a sub-project package

Focus on the meaning of this "routing" system for each package/content

For pages:
Provide unified jump rules, more controllable jump interception, greater ductility, etc. (this section can be seen in my previous article on Arouter: http://blog.csdn.net/ddwhan0123/article/details/54409574)

For a child package:
The mutual call relationship between all packages is absent, the coupling is reduced, all communication is routed to the routing to process the distribution (and the rules are held), and the registration is given to the main project for initialization. No matter how the sub-package changes (quantity and content), as long as the unified routing rules can be run unimpeded, instead of changing a place to move the whole body!

In the concept of a child package, routing is a rule and a chain of relationships .

The purpose of this is simple.

• testability Enhancement – Measure only the package you want to test, without having to control the chain of other packages
• reusability Enhancement – Similar base components can be used under different business groups
• Support for parallel development – you write what I write about mine
• Coupling reduction – Other libraries do not have dependencies other than the underlying library

The design does not consider the multi-process scenario, the large cluster project needs to consider separately

More architecture choices/knowledge points:
Https://github.com/googlesamples/android-architecture
Http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading
Http://www.open-open.com/lib/view/open1436316754208.html
http://keeganlee.me/post/architecture/20160222

If you have any questions, you can contact me:

The idea of application architecture based on routing mechanism design