聊聊架构-模块化

模块化的目的是为了降低程序的整体复杂度，使程序设计、调试和维护等简单化。各个模块可独立工作，即便单模块出现故障，也不影响整个系统工作。模块化具有三个特性：相互独立，可替换，通用。比如车载收音机就是模块化设计，收音机和汽车里的其他模块相互独立，收音机坏了不会影响车上的其他功能，具备独立性。因为汽车预留了接口，可以随意的将收音机替换成CD机和DVD机等，具备可替换性。车载收音机从汽车里取出来后，拿到其他车或者其他地方也是可以使用的，具备通用型。

模块化的表现形式可以是多个二方包或者一个Maven工程的子模块。系统中的公共组件可以抽取出来形成一个二方包，提供给更多的系统使用，比如业务系统里的任务框架，数据库锁组件和配置管理等。

如何划分模块？

• 基于水平切分。把一个系统按照业务类型进行水平切分成多个模块，比如权限管理模块，用户管理模块，各种业务模块等。
• 基于垂直切分。把一个系统按照系统层次进行垂直切分成多个模块，如DAO层，SERVICE层，业务逻辑层。
• 基于单一职责。将代码按照职责抽象出来形成一个一个的模块。将系统中同一职责的代码放在一个模块里。比如我们开发的系统要对接多个渠道的数据，每个渠道的对接方式和数据解析方式不一样，为避免不同渠道代码的相互影响，我们把各个渠道的代码放在各自的模块里。
• 基于易变和不易变。将不易变的代码抽象到一个模块里，比如系统的比较通用的功能。将易变的代码放在另外一个或多个模块里，比如业务逻辑。因为易变的代码经常修改，会很不稳定，分开之后易变代码在修改时候，不会将BUG传染给不变的代码。

易变和不易变？

根据代码的易变程度，将不变和变化的功能隔离，可以让代码更加稳定，减少代码的修改量，从而降低维护成本。从几个层面逐渐入手：

1. 系统分层：J2EE系统一般都划分成页面展现层，业务逻辑层和持久层。业务逻辑层容易变，而持久层变化小。对外提供服务系统分层是服务层，实现层和持久层，一般也是实现层不稳定需要经常修改，但是修改不会波及到持久层和服务层。将系统分层后，底层要更加稳定，可以新增接口或代码，但是尽量减少修改代码，因为底层一旦出错，影响面会非常广。系统间的分层也同样是需要底层系统更稳定。
2. 代码分隔：代码上分为接口，抽象类和实现类。抽象类和接口要做到充分的抽象，从而减少修改。比如接口要符合单一原则，避免接口修改。比如Java的Closeable接口里只有一个close方法，指责非常单一，所以无论未来有什么场景，基本不会修改这个接口。如果你的接口里有很多其他职责的方法，一旦一个方法修改，很多实现类就必须跟着修改。