技术架构与体系结构

Hexagonal Architecture(六角形或六边形) 于2005年由Alistair Cockburn撰写，是一个具

建立软件架构的松耦合的同时，也要建立团队组织架构的松耦合，这两种双解耦才是构建高性能软件组织的关键。通常按功能划分大型团队通常很诱人，我们拥有一个架构师团队，一个开发团队，一个DBA团队，一个测试团队，一个部署团队和一个运营团队，但这不能解决任何扩展问题，没有扩展就没有客户响应，这是团队响应

传统应用程序架构的标准三层或四层模型似乎决定了系统中各种对象之间的依赖关系的方向：UI依赖于应用程序层，因为UI“驱动”后面发生的事情；应用程序层依赖于业务对象，业务对象执行所有特定于领域的事务，业务对象使用（因此依赖于）持久层和通信层，这两个层又使用并依赖于外部API。以这种方式实现分层模

这是来自Michael Feathers的一篇著名文章，Negative Architecture消极架构已经被广泛传播。下面结合中国老子思想解释与翻译如下，从“无与有”角度理解“架构不做什么”反而是更好的选择：

从Google趋势来看UML没有增长，是否意味着已经死亡，UML（以及RUP，AOSD和Essence）的创建者之一Ivar Jacobson回答了这个问题：

本文作者作为很多年的资深顾问，看到太多公司和组织发生增长放缓，甚至是停滞和萎缩，主要因为他们在一开始时选择了错误的软件承包商。是错误的无法维护的软件架构制约了公司的发展，扼杀了公司的成长空间。 比如建房子：你想建房子。您提供的唯一指导原则是

使用由多个子视图组成的复合视图。整个模板的每个子视图可以整体动态地包括在内，并且可以独立于内容来管理页面的布局。 Apache Tiles和SiteMesh  框架使用Composite View Design Pattern。 为简单起见，这种模式分为若干部分，如问题，动因

我在http://alistair.cockburn.us/index.php/Hexagonal_architecture上发了一篇完整的文章。

ReactJS是前端开发的主力，但它在SOLID方面表现不佳我们可以通过采用经典方法来改变它吗？在将ReactJS视为UI的现代JavaScript解决方案时，很多人似乎在组织代码时遇到问题。让我们深入了解一下，看看我们是否可以做得更好。性子急的人可

在业务应用程序方面，您需要一个可以很好地扩展的体系结构。这是我的看法，基于Uncle Bobs EBI。尽管大多数人都认为我是DevOps人，但我经常在咨询项目期间使用业务应用程序，甚至在为DevOps企业编写管理软件时也是如此。在我这么多年的时间里，我意识到我编写代码的方式并不是非

在90年代中期的某个地方，我开始绘制一个对称架构，其中数据库不位于该架构的底部，而是完全在应用程序之外。为了打破过去那种“顶部和底部以及左右两侧”视角看法，我画了一个六边形的形状，并提出了相当愚蠢的名称：

架构决定（AD）是一种软件设计选择，针对功能性或非功能性的需求进行的选择设计。架构上重要的要求（ASR）是对一个软件系统的体系结构和质量衡量效果的要求。架构决策记录（ADR）捕捉AD，如经常做写个人笔记或会议记录时; 在项目中创建和维护的ADR集合构成其决策日志。所有

在讨论微服务时，经常出现有关软件架构的问题。许多微服务的新手不确定如何讨论架构以及如何做出决策。本文将解答这些问题，并分享一些其他建议。 整个系统的高级视图首先，无论您决定什么是处理架构决策的好方法，您都需

You can't optimise the architecture if you don't know the business model - @ntcoding #oredev