对模块开发卷宗的理解_java模块化设计：听够了模块化、架构、SOA！这三角关系怎么解？...

一、模块化与架构

模块化在软件架构中扮演着重要角色，作为一种中间技术，它填补了java开发一直存在的空白，那它是如何做到这一点的，我们如何定义架构？关于架构这个词有多种定义，这里我不会强调某种定义，而是在这些定义中的共同的关键词。说起软件架构你会想起哪些关键词？

• 【一系列重要决策】
• 【软件组织】
• 【结构化元素和行为元素形成系统的组合方式】
• 【组件】
• 【管理系统的设计和随时间演变的原则】

由这些关键词引出一些重要的问题，要理解什么是架构就必须搞懂这些问题：

• 什么原因使得一个决策具备架构上的重要性？
• 架构的组成元素是什么？
• 如何适应架构的演化？

回答这些问题前我们先来看看在一些功能失调的组织中，架构师和开发人员是如何交流的。架构师将他们的设计思想传递给开发人员，但开发者不能将这些高层次的理念转化为实现，经常出现故障，这是因为架构师关注的是广度而开发者关注的是深度，他们所理解的中间区域有一个空白，架构师关注的应用和服务，开发者可能更关注代码，但在他们各自的关注点之间还有很多事情。

架构师和开发者的隔阂

那么， 怎样消除和弥补这个中间区域呢？或许我们可以这样来看架构：项目中所有参与者对系统有一种共识，这种共识我们称为“架构”，包括系统分为哪些组件以及组件之间如何通过接口交互。这里我们突出【共识】，在这里【共识】就是我们的模块化设计原则。这表明架构存在社会性的方面，架构绝非只是技术理念，它更是一种社会性结构，通过架构的社会性，我们可以弥补架构师和开发人员之间的隔阂，

为了保证共识，开发人员不能仅仅关注代码，架构师不能仅仅关注服务，好的包结构设计和模块呢个帮助我们消除服务(架构师)和代码(开发人员)之间的断层，这能让我们实现自顶而下的结构，也有助于链接低层次的类设计和高层次的服务设计。

那么，架构目标是什么？如果以上你能理解，不难发现：架构的目标是减少变化的影响。说白了模块封装了业务实现细节，将变化带来的影响控制在有限的区间内，帮助我们减少了变化带来的影响和成本。

回答我们最初的问题：

• 什么原因使得一个决策具备架构上的重要性？如果变化带来的影响很大，那这样的决策就具备架构上的重要性。
• 架构的组成元素是什么？类、模块和服务。
• 如何适应架构的演化？灵活的设计方案可以适应变化，但灵活的设计代理复杂性，所以必须在系统合适的地方来有限的构建灵活性。

结论：模块化填补了高层服务和底层代码的空白，一句话就是模块化让架构实现了自己的目标——封装了变化从而减少了它带来的影响和成本，搭建起了架构(高层)和代码(底层)之间的桥梁

二、模块化与SOA

现在，可能我们会对模块化和面向服务的架构(SOA)之间的关系有些疑惑？某种角度来看服务设计和模块化设计的原则是相同的，服务设计我们提倡高内聚低耦合，同样的设计模块是也有同样的特性，实际上他们有很强的互补性，模块化是实现进程内的重用可选方案，而服务是跨进程的。

自上而下的架构能够帮助开发人员和架构师之间增加透明度，看看这张图，我用虚线展示了平时开发中可能会忽视的断层：

自上而下的社会化架构

可以看到这是一种自上而下的社会化架构，它带来一个重要优势——结构的灵活性

自上而下的结构化架构

一般在应用内部，类很容易实现重用，但是类不是部署单元，所以很难跨应用重用，服务(SOA)便成为跨应用重用最佳选择。这就带来另一个问题：如果服务太粗了。。。 额。。。就是设计过于粗粒度了。

那如何跨应用重用某些行为呢？不考虑模块化的前提下，唯一的选择就是类，但必须类暴露为服务或者把类代码复制到到其他需要的地方，这也太low了吧！

此时我们自然想到了模块化是一种不错的选择，模块比类粗比服务小的粒度并且java模块化的思考系列——模块的定义也提到了模块是可独立部署的，这种适中粒度让我们可以用非常灵活的方式组装服务(SOA)

像拼图一样任意组装服务

这也增强了适应架构变化的能力，总的来说，细粒度具备更高的重用性，而模块的粒度介于类和服务之间，既可以组装为不同的服务，又可以封装底层类的复杂性。

下一篇我将讲解【模块化如何征服复杂性和实现重用】，个人理解有所纰漏，还请老铁们多多指教！