一次关于架构风格与协同之间的讨论，激发出来自己的很多思考，遂整理出来，与大家分享。

讨论的主要内容有三点：

1、架构风格与应用框架
2、时间、成本和范围的平衡
3、演进式架构的考虑

关于第一点，在读《架构整洁之道》一书中就提到过，包的组织形式决定了架构的设计风格，如下图所示，从左至右分别是按层封装、按功能封装、接口和适配器和按组件封装。

这里衍生的另一个问题，就是框架的使用问题。

其实，无论是哪种架构风格，尤其记住一点，请不要嫁给框架。我们可以使用框架，但要时刻警惕，别被它拖住。另外，不要让框架污染我们的核心代码，应该依据依赖关系原则，将它们当作核心代码的插件来管理。以 Spring 为例，千万别在业务对象里到处写 @Autowired 注释。业务对象应该对 Spring 完全不知情才对。—— 摘自《架构整洁之道》

所以关于第一点，我认为架构风格是由个人的工作经历所决定的，不应该定义唯一的执行标准，在协同过程里应采用实践标准来因地制宜。现代微服务的概念：微服务是一个通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中。—— 摘自《凤凰架构》

而关于框架的使用，这里包括一些工具类和组件的使用，我个人觉得，无论采用何种技术，前提是对应用技术有足够的了解，或有对应的技术专家提供支持，否则，若团队里仅一或极少人熟悉某种技术，这是不建议使用的，因为这将成为极大的隐患。

比如，我要安利某一个技术，首先我会进行技术的调研以及源码级的分析，其次是进行团队内外的布道和分享，在充分论证的情况下，我才会进行业务架构的逐步尝试，并通过灰度和A/BTest等模式验证后，最终完成某一技术在团队内的推广。

关于第二点，架构没有对与错，每个人站在不同的视角看的都皆不相同，而架构的选择，唯有在时间、成本和范围三者之间进行平衡，由此得出的架构才是当时最合适的架构设计，当然在未来某个时间点在回看，它又可能不是合适的设计。所以，任何架构设计是否合理都是有环境的。

此外，随着技术的发展，技术就会被淘汰，而这也侧面要求架构的设计，不应该是大而全的，更应该是面向更易删除的。从分布式架构的发展史来看，从SOA演进到微服务架构，就是一场大道至简的变革实证。

从上述两点，就进入关键的第三点，多人开发在架构风格不一致时如何进行协同？

也许这不是个大问题，但是想想配置、框架、中间件的技术选型各不相同，出现百家争鸣的情况，这不仅会出现重复造*的糟糕情况出现，还会迅速的将系统拖入焦油坑。这就不得不使人慎重对待。

其实，问题也远远没我们想的那么复杂和困难，Spring的架构设计理念提到了约定大于配置，那么，在协同开发过程中，是去中心化的，架构的演进是一个团队共同的努力，而非一二个人的成果，尤其在现在大型复杂分布式系统架构时代，能将一二个点做到极致已是优秀，否则就不会有协同问题了。所以，共同的认识是必须的。

那么，稳定性如何得到保障？其实，随着软件架构演进，构建可靠系统的观念从”追求尽量不要出错“到正视“出错是必然”的转变，才是微服务架构得以挑战并逐步取代单体架构的底气所在。—— 摘自《凤凰架构》

而且，微服务时代涌现了很多现代架构的设计的基础理论，其中康威定律就定义了系统架构由组织架构所决定，那么，在领域驱动设计已经逐步应用落地，系统架构设计在后微服务时代里，通过领域进行架构模块的拆分和职责的定位，已经是团队分工协同首要利器。

也许，这很浪费时间，但这是一种负责和谨慎的态度，尤其是对自己学习的负责和对业务的负责，其次，最后关于第三点说一点，架构永远是演进出来的，而绝非定义出来的。

我始终认为，你可以指出别人代码逻辑的对与错，但不能指责别人代码风格的好与坏，这主要是因为你不了解对方所解决问题的场景。

此外，尤记之前记得的一个故事，别人在遇到问题时，就像一个山挡在了他的面前，而此时对你可能就是一块小石头，如果你能勤勉多去助人去拾取这些小石头，最后，你可能就会站在一座大山上，而这就是架构师影响力的建设。反之，你总是将自己面前的小石头放到别人面前，最后，你可能就会处在一个洼地里，届时，就会很难有人与你合作了。