“所有模型都是错误的，有些模型是有用的” - George Box

好与坏没有统一的标准。以下是我定义良好软件架构的 AAA 原则：

• 负责：良好的软件架构使每个团队对其相应的业务目标负责

• 自治：好的软件架构应该允许每个团队在很大程度上独立地前进，而不会太频繁地被其他人阻止

• 摊销：良好的软件架构促进前瞻性思维，允许摊销基础设施的前期成本

负责>>自治>摊销。上世纪 90 年代，代码重用（Amortization）是面向对象社区的热门话题。然后 SOA/DDD 非常强调自治。但是我发现 Amortization 和 Autonomy 在指导实践中的边界定义时都是模棱两可的。很难说服人们，X 比 Y 好。实际上，一个模块的功能应该来自它的职责。

开发商无法估计

“负责”确实是这里的关键。我看到“缺乏问责制”是软件开发最大的危机，它比“无法管理所谓的复杂性”更大。

这不是开发人员无法估计的秘密。它给优秀的软件工程带来了很多非常基础的问题：

• 因为我们永远不知道真正需要多少人，中层管理人员只会在人数允许的情况下增加人数。为什么？很简单，他们根据他们目前管理的人数获得报酬。

• 重构软件以使其“可维护”没有商业价值。可维护是什么意思？把足够多的人投入到问题中，它总能得到解决。软件工程不是火箭科学，它有多难？

解决这个问题不是要搞清楚故事估算的魔力，相反，我们不需要估算我们是否与业务所有者作为同一个团队一起工作。每个软件团队都会有一个并且只有一个对应的业务团队，他们共享完全相同的OKR。只对一件事负责是很重要的。

这是典型的企业组织结构图。每个较小的团队都会将他们的 OKR 与他们的母团队保持一致。OKR 的关键结果将是可衡量的，这样每个团队都可以对某事负责。

典型的糟糕的软件架构是这样的：有很多小团队拥有他们的微服务。企业主通常需要多个微服务的支持来实现他们的目标。每个需求都需要一次又一次地传达给不同的软件团队。软件团队无法为他们的微服务命名一个明确的业务目标，因此，他们无法说出他们对业务做出了什么贡献。

再次强调：软件架构的NO.1目标是让软件团队对业务负责。

有界上下文

在大规模上，架构是关于有界上下文（阅读 DDD 了解更多细节）。这只是反映在软件世界中的业务组织结构图：

以电子商务领域为例，将业务划分为多个有界上下文。没有一个团队可以跨越有界上下文来涵盖业务流程。这在这里通常是一件好事，大问题被分解成小问题，业务和技术团队可以在一个有限的上下文中朝着共同的目标努力。

网络空间和代理

一个有界上下文对于一个团队来说仍然太大。至少我们相信微服务思维就是这种情况。如何将其进一步分解为更易于管理的部分？我的模型是“网络空间和代理”。我们作为程序员正在构建的东西基本上归结为两件事：

• 网络空间

• 有点聪明的代理人在网络空间与我们互动

网络空间是一个虚拟世界，就像我们生活的物理世界一样，它是基于因果关系的。有两种法律：

• 自然法：自然本身如何运作

• 社会法：模仿自然法创造社会秩序的人造系统

重力是自然法则的一个例子，“你还债”是社会法则的一个例子。两者作用相同，有因必有果。我们使用 C/C++/Java/Go/... 任何你喜欢的描述。从光线追踪算法、文字处理器到电子商务平台，都或多或少地将一些规则烘焙到系统中。“法律”需要是静态的和可预测的，就像水泥一样，构建了现实世界。

在我们建立的网络空间之上，我们作为人与人之间的互动，从社交网络到交易。人类所扮演的角色越来越多地被我们编写的人工智能代理所取代。例如，不是编辑挑选内容，而是机器人为您生成新闻和准备主页。代理越来越复杂，总有一天他们会从网络空间出现到物理空间。

这两种代码的工作方式非常不同。网络空间产生因果关系以维护自然/社会秩序。智能代理收集效果以推断模型以最大化某些目标。将智能部分与系统的其余部分区分开来至关重要。我们作为人类需要静态的规则来建立稳定的期望。如果“法律”不断变化，网络空间将像一个“神奇”的地方，与我们在现实世界中的体验失去联系。

模型、视图和控制是网络空间。人和机器人是智能代理。该模型根据自然或社会规律定义的因果关系维护数据完整性。为方便起见，视图和控件为人/机器人提供了一个界面。

所有权 == 作者身份

网络空间部分仍然太大。它通常是多步骤的业务流程。例如

并且有界上下文相互关联。例如

问责问题源于我们使用的编程语言并没有涵盖整个因果链。我们可以在白板上整体画一个流程图，但是我们必须把它分解成许多小的服务/功能来实现它。工作流引擎经常被提出，因为它很好地映射到问题域，但 BPMN 不是一种编程语言。

步骤之间有很强的因果关系。商品详情中显示的促销需要在购物车中显示，在结帐中显示，并将应用于最终收据。我们使用的“函数”，只能用来描述500ms时间跨度内的伤亡。我们必须将过程分解成小步骤，或者分解成为不同角色的用户提供服务的不同服务，因果关系隐藏在凌乱的实现中。该软件就像接力赛一样运行，一个服务将责任转移给另一个服务。理想情况下，代码应该反映流程图，读起来像流程图。

更糟糕的是，对于谁应该做什么没有强硬的界限，这经常导致团队之间关于责任的争论。高度政治化的环境让开发者不高兴。同时，具有讽刺意味的是，当事情向南时，没有人可以对整个事情负责，因为每个人都只是从整体中剪下一小部分。

当前解决此问题的最佳实践是让外观团队负责一切。“所有权=作者权”，我们只愿意拥有我们所写的东西。这是人的本性。为了让这些人有一种主人翁意识，我们允许使用瘦代理/包装器或编排服务来粘合微服务。这往往会导致自主性低。

理想的编程语言应该提供“功能”来描述业务流程。几个并发的因果链将通过消息传递相互关联。这样，我们可以为每个业务流程分配一个单独的软件团队。他们可以对自己负责的事情 100% 负责。与人工操作者和机器人组成一个团队，对损失负责，对收益负责，而不是共享成本中心。

合作单位

还有一件事被打破了。语言提供的模块单元，例如程序集/包/类，曾经是我们相互协作的单元。这不再是事实。软件模块需要单独进行版本控制和部署，以支持多个独立工作的团队。

但是我们是否“总是”需要为不同的微服务使用不同的语言和不同的工具？语言差异和断开的工具使跨团队沟通更加困难。你可以拥有你的流程，拥有你的服务，但这不应该阻止你与你的伙伴分享相同的语言。一种编程语言扮演 3 个不同的角色：它连接机器、开发人员和团队。今天，编程语言主要用作将机器与人联系起来的工具，使团队在大局中处于脱节状态。技术参考《曲阜市智程网络科技有限公司》

解决方案应该把软件看成一个整体，而不是被单一“操作系统进程”的狭隘观点所限制。引入一个新的微服务的成本应该和在一个单独的包中启动一个由函数支持的单独线程一样便宜。理想的编程语言不应平等对待所有函数调用。