Some thoughts about componentization of terminal service

Modularization and business componentization

In the terminal development often because of the complexity of the project more and more high, but need to keep a business to do classification and grouping, called modular in Android, significance of the modular is to do business and project code level separation, thus finally do business segregation and code reuse, this kind of thought also reflected in other platforms, Such as the separation of the front and back ends of the WEB. In Android, the architecture after the final module is generally as follows:

The upper layer can depend on the lower layer, and the business modules cannot depend on each other before. The benefits of this are:

• Because business modules cannot be relied upon, the services are theoretically isolated, each requiring only a small number of people to maintain.
• Newcomers are easy to get started, just need to understand the current business module.
• If the problem is manageable, modifying the code will only affect the current module.
• For large apps, the APP code of multiple departments can be divided into multiple Git libraries, and each department can manage its own code separately, which can be merged together when packaging.

Of course, there are some problems in the process of modular construction. The two biggest problems I encountered in practice are:

• Division of business. This is a non-technical problem, how to make accurate division of the business, which involves the product level and the company strategy level. In short, a modular build should serve the business of the company and the business of the division.
• How modules communicate with each other. Although the business is divided, there will be coupling between business modules no matter what. For example, the authorization system belonging to the account module may be called by other modules and return data.

The first problem is a business one that requires the project leader to make decisions based on the current situation of the company. The second problem in the industry actually have a better solution, modular practice is the best wechat, wechat Android modular architecture reconstruction practice this article for the second problem has its own solution (lib way). This solution is also a good approach for projects with less stringent departmental isolation requirements.

Mention are modular, business componentization really belongs to the modular a subdivision, modular from big business level code for carding and isolation, and business componentization notice is componentized UI level, but also more coarse-grained than UI components, business componentization, like the building blocks blocks is this component. You can imagine a page consisting of a product list and a buy button, where the product list and the buy button are components. The buy button is not just a button, it contains the entire purchase logic:

• Purchase product information input and settlement
• Purchase process handling
• Data return and exception handling

Essentially, business componentization for an endpoint is a business-specific UI component that can input and output data for many similar scenarios and handle a specific business.

The advantages of doing so are obvious

• With predefined components, the development effort is greatly reduced.
• It is highly configurable and even allows the server to dynamically generate pages by delivering the configuration.

Difficulties in business componentization

In terms of technology, Android business componentization is not essentially different from other project componentization. Other componentization issues need to be considered:

• Management of multi-business components, component manager.
• Management and definition of the business layer, the business layer.
• Communication mechanism between components, communication layer.
• The definition of the basic UI component, the UI layer.

According to the above ideas, a rough drawing

In order to prevent component coupling, a communication mechanism between components needs to be designed. This communication module design principle is similar to modular communication. Personally, I think this kind of componentized design is not difficult, just need to consider the reuse and ease of use when designing.

So what’s the hardest part about componentizing a business?

Personally, I think business componentization is not difficult in the coding stage, but the real difficulty lies in the stage before coding:

How do product managers define business components?

How can designers standardize uniform style business components?

These two problems test the unity and coordination ability of the whole project, the planning of the whole project and the strategic direction of the whole company.

How does a product manager define a business component?

• Consider this a business component?
• Does this need to be reused or changed later?
• What possible changes need to be defined in advance?
• Are similar features consistent across the project?

These issues have nothing to do with technology. They have to do with product thinking and overall company strategy.

How can a designer define a set of components that have a similar style?

• Is there a standard UI specification for the entire project?
• How can each designer create a consistent design?
• How can technology comply with this design specification and form a general-purpose UI component?

Consider a logon authorization component. In general, the process might look like this:

Users click a login button on the page – “to jump to an authorization login page -” users input authorization information – “according to the user’s authorization information, through the server to verify -” return the authorization result.

Among them, designers may need to consider:

• Is the login authorization button style fixed and should be excluded from business components?
• Is the authorization page public throughout the project? Does the design style change from page to page?
• How will users be notified of exceptions throughout the component process? How to make consistent feedback and design?

The product manager may consider:

• Does this licensing system require product reuse?
• Do interfaces need to be reserved in advance for different user types of authorization?
• Is the uniform style consistent with the product intent?
• How to handle abnormal cases?

The entire process, if not clearly communicated, can result in the failure to define the entire business component. Login authorization is still a simple business. If you encounter a product with a complex business like Alipay, you need to consider these issues before developing the product.

From a technical point of view, the sooner the business components are defined, the easier it is to implement, and the easier it is to implement when the business is not yet rolled out and the code complexity is low. Therefore, business componentization should be an ongoing process, especially for a rapidly iterating project, throughout the entire product development process.

conclusion

Business componentization is very difficult to implement, often not because of technical issues, but mostly because of product issues. Of course, it is also very important for an authoritative and knowledgeable product owner to promote business componentization across departments. Therefore, if you want to implement business componentization, first sort out the project from the product level and select a reliable and authoritative person to promote it.