“This is the fourth day of my participation in the Gengwen Challenge. For details, see” Gengwen Challenge “.

Architecture design

Application architecture

Common module design

define

  • What is a common module? It comes from code blocks or logic that can be used by multiple modules. It can be extracted and encapsulated into independent modules, which can be introduced when needed to improve the reusability of code, reduce the amount of repeated code, and improve the maintainability of code.

Design principles

  • When it comes to the design principles of public modules, this is an interesting topic. Some people think that public modules should be developed completely independently and refuse to use third parties because of uncontrollable factors. For example, license, there are unknown risks (the most impressive is the 18th Ant Design Christmas Egg event, of course, here is not to say that Ant Design is bad, after all, everyone makes mistakes. Interested students can go to see); Some people think that good solutions on the market should be integrated so that they can focus on the business domain. Of course, there are certain risks, which need to be done well in the early stage;

  • In terms of start-up companies, the author believes that these two schemes should be combined to grasp the boundaries of independent development on the one hand. After all, it’s unrealistic for startups to be completely autonomous at first. On the other hand, the integration industry is more famous and the version is relatively stable, and the open source protocol is more friendly.

The backend uses Java Web as an example.

1. Unified version
  • Facilitate follow-up unified management and maintenance
Avoid multiple dependencies between common modules
  • If module A is referenced by module B and module B is applied by module C, appropriate dependencies are allowed
3. Clear boundaries
  • Here are some examples
/ /
-- xxx-common
    -- xxx-common-redis
    -- xxx-common-idempotent
    -- xxx-common-lock
// Example (1)
-- xxx-common
    -- xxx-common-idempotent
    -- xxx-common-lock    
// (2)
-- xxx-common
    -- xxx-common-redis
Copy the code

4. Single responsibility

  • Avoid references to useless logic or JARS, increased project size, and subsequent conflicts in order to use a feature.

5. Unity of split dimensions

  • The following examples are for reference only and need to be more practical in development
5.1 By Integration Dimension
-- xxx-common
    -- xxx-common-support
    -- xxx-common-mybatis
    -- xxx-common-redis
    -- xxx-common-spring
Copy the code
5.2 By Functional Dimension
-- xxx-common
    -- xxx-common-api
    -- xxx-common-entity
    -- xxx-common-dto
    -- xxx-common-idempotent
    -- xxx-common-lock
    -- xxx-common-feign
Copy the code
5.2 By Type Dimension
-- xxx-common
    -- xxx-common-spurt
    -- xxx-common-enums
    -- xxx-common-config
    -- xxx-common-exception
    -- xxx-common-constant
    -- xxx-common-cache
Copy the code

6. Degree of encapsulation

Excessive encapsulation is not recommended at the beginning of the project, especially when the business is not familiar with a high degree of encapsulation and extraction. The first reason is that some modules may not be used. The second reason is that it increases the difficulty for the coder to be familiar with the project and increases the learning cost. At the beginning, it is suggested that simple abstraction can be slowly improved in the development process. Of course, some people will say that they have entered the development phase and have no time and energy to maintain and optimize the common modules. This is undeniably true, and this is the case in most cases. Of course, it depends on whether the leadership of the company takes this seriously, or it will go too far in terms of code quality.