反模式的模式：体系结构

我们一直在寻找构建我们的应用程序和平台的最佳方法，以便它们可维护，可扩展，可观察，适应性强并且易于演化（这绝不是我们想要拥有的属性的完整列表，而是基础属性的完整列表） ）。 分层体系结构 ， 基于组件的体系结构 ， 六边形体系结构 ， 微服务体系结构 （以及许多其他 体系结构 ）主张使用出色的设计原则和指南来实现这些目标。

例如， 分层体系结构建议在不同的层（持久性，服务，缓存，表示等）之间实现清晰的分隔，并对各层如何相互通信施加严格的规则。 基于组件的体系结构在UI开发领域中非常普遍，但不仅限于此，它介绍了组件（内部可以构建在分层体系结构或其他体系结构样式之上）作为应用程序或系统的关键构建块。

反过来， 六角形架构通过在应用程序核心周围引入端口和适配器的概念而变得更进一步。 最后但并非最不重要的一点是， 微服务架构 （当今最热门的架构样式）提倡将应用程序或系统构建为一组相互协作的松散耦合，理想的小型自给式服务。

上面提到的每种建筑风格（以及我们没有提到的其他风格）都具有自己的强项/弱项，并且在上下文中最耀眼。 但是有两种架构胜过所有架构，我们将立即讨论它们。

邻近架构

这种建筑风格仅提供一个原则：在任何需要的地方使用任何想要的东西。 您是否需要从数据传输对象访问服务？ 没问题，就做吧！ 可能您的RESTful资源需要访问持久性服务？ 没问题，去吧，因为总的来说，为什么要打扰？ 它只是一堆类（通常在同一应用程序中），使用静态字段或方法，依赖项注入或您的语言/框架提供的任何其他技术。 最后，如果编译器满意，那么问题是什么？ 对？

不，这是不对的……当然，您听到过诸如“大泥巴”或“意大利面条代码”之类的有趣术语。 当接近式架构带动演出时，这些就是典型的结果。

邻近架构出现的原因很多。 这些原因包括对不断推出功能的迫切需求，对软件Craft.io的了解和/或经验不足或最坏的情况，对软件工程学科的道德和粗心做法。 如果您碰巧有创业经验，或者曾在那些仍声称自己是一家新兴公司来证明自己混乱的大公司中工作过，那么我相信您已经看到了这种形式的架构或其变体之一。 他们都注定了吗？

好吧，我会说，不是，不是真的，而是逃避邻近架构的利爪完全取决于您将要做出的取舍。 对于开发人员来说，很难甚至不可能推迟提供新功能的时间表（除非您非常幸运，并且您的经理了解什么是技术债务以及如何控制它）。 您必须这样做，您将采用捷径。 但是，在注入hacky代码（在其他hacks之上）与选择快速/不是最佳选择之间保持适当的平衡（这对整个应用程序架构可能造成多大的伤害（以及稍后重构/改善/逆转的难度）。 毫无疑问，经验丰富的软件开发人员可以解决这一问题。

我知道，作为可行的建议听起来很模糊，但是每个公司都是独一无二的，没有任何神奇的通用规则或秘诀可以阻止邻近体系结构污染您的应用程序。 但是，有一件事很清楚，如果您让它什么也不做，那么您将得到难以管理的代码库，而唯一的选择就是从头开始重写所有内容。

微型整体架构

微服务 ， 微服务 ， 微服务 ......每个人都对他们的会谈......你听到来自左右，如果你不这样做微服务 ，那么你是停留在石器时代。 实际上，许多人真正相信使用微服务可以解决所有问题。

在许多方面，假设您已准备好在整个组织中从文化和技术角度接受微服务架构 ， 微服务架构都可能使停滞的项目陷入生机。 这是一项严肃的长期承诺，因为这种改变不会在一夜之间发生。 但是，如此众多的组织未能看到新的野兽在这里兴起：微服务服装中的微单块架构 。

这就是您可以作为微服务架构出售的东西。 许多组织最终都陷入困境，别无选择。 质量太差了，生产力下降了，发布新功能要花费几个月（甚至几年）……而且让更多人参与其中完全没有帮助。 因此，每个人都试图逃脱巨石，无论花多少钱，都在一边构建独立的应用程序或服务，幸运的是，出色的Spring Boot使它像掉日志一样容易。

乍一看，它看起来还不错，毕竟他们将其称为微服务 ，并且很多东西相互调用，对吗？ 除非这根本不对。 在这种不健康的生态系统中蓬勃发展的应用程序和服务通常不拥有任何数据。 他们没有足够的知识来独立运作，也不属于具体领域。 这类服务需要与整体通信，以执行任何有用的功能，并且在最坏的情况下，它们与整体共享一个数据库，并成为单纯的聊天代理。

这是为什么？ 好吧，因为在大多数情况下，很难将大型的单片应用程序迁移到微服务架构 （真正的应用程序）。 并且随着迁移，该组织应该自然地转型，成为培育微服务的沃土。 不是每个人都敢于实现这一目标，但好消息是可行的。 这就是为什么。

在构建整体时，组织（希望）成为其领域的专家。 产品周围积累了大量的知识，定义明确，易于理解的用例和流程， 领域驱动的设计对于形式化和捕获所有内容可能会大有帮助。 一旦对应该建造什么有了扎实的了解，就该开始从整体上切下碎片了。 当然这将是一个坎bump的旅程，可能您将无法直接从A点到达B点（重构？将整体拆分成模块？），更不要忘记不断发展的测试实践 （消费者合同测试？组件测试？e2e测试？）。 但是回报值得付出努力。

微服务架构是一个很棒的架构 ，它提供了无限的机会，如果做得正确，它可以带回开发的乐趣，可以为组织的软件堆栈（当前和将来的堆栈）奠定坚实的基础。 但是，忽略其核心原则将为沮丧和混乱铺平道路。

翻译自: https://www.javacodegeeks.com/2017/07/patterns-antipatterns-architecture.html