项目模块间交互的一个设计思路及其延伸

 

 

 

 

1.背景

　　某API项目，项目自然地按业务分为了避免同的包，那么每一个包都独立处理本身的业务逻辑，独立接管数据源，独立地向外部提供数据，彼此基本互不通讯。

　　不过，随着需求的增多和业务的堆积，项目的复杂度愈来愈大，可是每一个独立模块却又不足以独立出去成为一个单独的项目，而模块间又因业务须要开始发生交互的时候，问题来了。　

 

2.问题描述

　　因为模块间的数据交互，按照Spring的套路，是能够直接把容器接管的对象注入到你须要的地方去的，那么一旦你开始问其余模块要数据，开始要命了。如上图，若是模块3问模块2和模块4要数据，理论上来讲，他是否是能够随意注入这两个模块的各类服务呢？

　　答案是确定的。这个时候你会发现一个问题，因为原本在一个模块内某个数据源可能通过多重必要的封装再提供接口数据的，可是其余模块他并不知道这一点。因而他极有可能注入数据源在封装的过程当中各个阶段的服务类，也有可能直接注入了最底层的数据接口，他再去作本身的逻辑处理去本身封装一遍。这样，漫天飞舞的入侵完成了，这个地方飞满了各类各类的花蝴蝶，简直眼花缭乱，一片失去控制的景象。

 

3.解决思路

　　这个时候笔者想到是否能够把某个模块的各类数据服务汇集到一个服务中去呢，对外部（其余模块）来讲，约定好只容许调用我这个公共的服务接口，我对外部屏蔽掉全部逻辑，你外部也不用关心个人数据怎么来的，你只要问我这个接口要数据便可。如上图所示，

到此问题基本能够解决，优缺点也在图中描述了。

 

4.深刻

　　接着，笔者发现其实这个设计思路，相似于门面模式，或者说就是门面模式。网络上找来了门面模式的意图：　

• Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
• 对子系统中的一组接口提供了一个统一的接口。门面定义了更高层次的接口，使子系统更容易使用。
• Wrap a complicated subsystem with a simpler interface.
• 以简单的接口包装复杂的子系统

　　能够看到，笔者文章中所说的能够被视为是门面模式的一个应用场景，虽然不是系统级别的交互而只是模块之间的交互，可是笔者相信这样去设计至少在接口的易用性和模块间的解耦程度上，是能够作到有所提升的。至此，门面模式get。

　　维基百科传送门：https://en.wikipedia.org/wiki/Facade_pattern