——悲伤的柚子Box
没有普遍正确的好标准和坏标准。 介绍衡量软件体系结构好坏的AAA原则。
可审核(Accountable )良好的软件体系结构使每个团队都有自己负责的业务目标
自主性(Autonomous )良好的软件体系结构使各团队能够拥有一定的自主性，独立前进，而不是总是被其他团队阻止
良好的软件体系结构鼓励投资未来，以补偿可重用(Amortized )基础架构的成本
审查可以自主重复使用。 20世纪90年代，代码复用是面向对象社区的热门话题。 而且SOA和DDD还会告诉我们“自主”是最重要的。 但是，实践中发现，“自主”和“可重复使用”都很模糊。 用这两个原则很难说服别人，但用x方式解决问题比用y方式解决问题好。 但是，如果说这样分解可以让各队更好地评价，那就更理所当然了。
开发者无法估计工作量
“可审查性”是所有的关键。 “缺乏可评价性”是当前软件开发模式的最大危机，我认为这个问题比“无法管理所谓的复杂性”更为严重。
开发者不能估计工作量，在业界也不是秘密。 这带来了许多根本的问题：
因为我们真的不知道需要多少人才，所以中间管理总是尽量增加人手，而不是招聘人数的上限。 为什么要这样做？ 很简单。 他们的报酬与他们管理的头数成正比。
将软件重新构建为“更可维护”是“没有商业价值”的。 什么是保守性？ 如果不能解决问题的话，投入更多的人总是可以解决的。 软件工程不是制造火箭，有多难？ 不能证明通过重构可以节约多少劳动力。 因为在目标重构之前没有应该投入的人才。
我认为解决这个问题不是理解开发工作量评价的魔法。 相反，如果我们和业务负责人在同一个团队工作，就不需要估算工作量。 每个软件开发团队都有“唯一”需要应对的业务团队，业务团队背什么样的OKR，技术团队背什么样的OKR。 要让团队进行评估，最重要的是只对一项业务负责。
上面是典型的组织图。 各队的OKR必须与上位队的OKR一致。 如果OKR中的重要成果是可衡量的，那么各团队就可以对真正存在的事情负责。
典型的糟糕的软件架构看起来是这样的。 有很多微服务团队。 业务人员为了实现他的目标，必须经常直接寻找多个微服务团队。 每个需求都需要与多个不同的软件团队进行重复的交流。 任何技术团队都无法清楚地了解他们及其微服务所负责的业务目标是什么。 因此，技术人员们无法清楚地说出自己对业务有何价值。
让我再次强调一下。 软件体系结构的“最大目标”是确保所有分解的团队能够拥有和负责业务目标。
联合上下文
在大规模上，体系结构是分解Bounded Contexts (域驱动开发，参见DDD )。 这是在软件世界中反映业务的组织结构图。
以电子商务领域为例，业务分解为上述的Bounded Contexts。 没有技术团队能够涵盖跨越这些Bounded Contexts的业务流程。 这并不是坏事。 大问题分解为小问题，业务和技术在一个Bounded Context的范围内，携手朝着共同的目标努力。
虚拟空间和智力
Bounded Context对球队来说还是太大了。 至少在微服务的心理上是这样认为的。 如何将其分解成更可管理的小块？ 我的模型是“虚拟空间和智慧体”。 简单来说，我们作为程序员所做的有两件事：
虚拟空间
稍具智慧的“机器人”与我们人类一起在虚拟空间中互动
虚拟空间和我们肉体所处的物理空间是相同的，它基于因果关系。 有两条支配这些因果关系的法则：
自然规律：自然自身的内在规律
社会法则：通过模仿自然法则来制作稳定的规则系统，构筑稳定的社会秩序的人工系统
例如，重力是自然规律。 另外，“还债”是社会的法则。 两者的工作方法相似。 给定某个前因，根据规律，必须得到某个结果。 使用C/C /Java/GO/……等记述这些法则。 从光线跟踪算法到word文本编辑器到电子商务平台，从规则构建的角度来看基本相同。 “定律”必须是静态和可预测的。 就像用水泥构建了我们的现实世界一样。
在我们构建的虚拟空间的智商中，社交网络和交易等，作为人类相互交流。 人类hsdyj正在被我们省略的人工智能的“机器人”所取代。 例如，以前由人工编辑选择内容，但现在可能准备了机器人生成新闻，每天打开屏幕的首页。 “机器人”越来越复杂了
天他们会从虚拟空间里出来，直接走向物理空间。“虚拟空间”和“机器人”这两种软件代码的工作方式差异性是很大的。“虚拟空间”从原因推导出结果，来维护自然和社会的秩序。“机器人”的工作方式是相反的，它收集事实反推出模型来最大化其目标。把智能的部分和系统的其他部分明确地区分出来至关重要。我们作为人类希望规则是静态的从而构建出稳定的预期。如果“法则”总是不断在变，“虚拟空间”看起来就像是“魔法空间”，它就变得和我们从真实空间获得的生活体验很不一样了。
软件开发中的Model，View，Controller(MVC)的概念可以用来解释“虚拟空间”。人类和“机器人”是所谓的智慧体。Model根据自然和社会法则定义的因果去维护数据的完整性。View和Controller提供了便捷的接口给人类和“机器人”去交互。
所有权==著作权
“虚拟空间”这部分仍然太大了。业务流程可能会有很多个步骤，例如：
而且不同的Bounded Context的业务流程之间也是有集成关系的：
可考核性问题的根源是编程语言里缺乏对完整因果链的直接描述能力。我们可以在白板上画一个清楚的业务流程图，但是在写代码的时候就不需要切分成很多细碎的服务和函数来表达。之所以工作流引擎总是被拿出来考虑，因为它的描述能力和要解决的问题有良好的映射。但是BPMN并不是一种编程语言。
步骤与步骤之间有很强的因果关系。在产品详情页展示的促销，也应该体现在购物车里，也应该体现在收银页面上，也应该体现在最终的收据里。我们使用的“function”的概念，顶多只能用来描述500ms内发生的事情的因果关系。对于前面所述的业务流程，我们切分成了很多个步骤，同时又按照使用方的不同，切成成了很多个面向用户的服务。从而因果关系就被隐藏在这些庞杂的实现细节之中了。软件跑起来就像一场接力赛，一个服务把职责接过来，搞一搞之后，又传递给另外一个服务。理想的情况是，代码本身就应该体现流程图，读起来就像流程图。
更糟糕的是，现在的切分方式并没有明确的划线的原则。这就频繁导致了团队之间关于谁应该负责什么的争论。高度政治化的组织氛围导致了开发者情绪上的沮丧。同时，具有讽刺意味的是，在大家彼此抢活的同时，又因为职责切分得太碎，导致又没有一个团队能够对全局负责。
对于解决这个问题，目前能够做到的“最佳实践”就是在一堆微服务团队上架一个门面团队。“所有权==著作权”，我们只愿意对自己所写的东西负责。这个人性，无法改变。为了给这些可怜的家伙具有所有权的感觉，我们必须允许一层很薄的代理层，或者叫所谓的调度服务来把微服务给“屏蔽"在后面。但是这种代理一层的做法经常导致了很低的团队自主性。
理想的编程语言，应该能够提供“function”一样的东西去直接描述业务流程。业务上的同时行进的并发流程应该可以像多线程编程一样，用消息传递的方式来描述。这样，我们可以给每一个可切分出来的业务流，分配一个独立的软件团队去端到端负责。他们可以对自己负责的事情100%负责。这些人和业务运营人员，以及编写出来的“机器人”合在一起作为同一个团队，共同负责这个业务流的收益和亏损。而不是单独把技术摘出来，成为一个共享的成本中心。
协作单元
除此之外，还有一个事情是有问题的。之前由编程语言提供的模块化单元，例如assembly/package/class这些，就是我们团队之间彼此协作的单元。然而现在不是这样了。现在越来越多的人，要求软件模块有独立版本，能够独立的部署。因为这样才能支持多个团队的独立性。这就导致了大量的微服务的做法。
但是我们是否“总是”需要用不同的编程语言不同的工具来实现微服务?语言的差异和彼此割裂的工具导致跨团队沟通更加困难。你可以拥有你的流程，拥有你的服务，但是这不阻碍你和你的伙伴们用同一门语言啊。一门编程同时扮演了3个角色：它连接了机器，它连接了开发者，它同时又连接了团队。今天编程语言更多是仅仅作为一种连接机器和开发者个体之间的工具，团队之间宏观上是彼此割裂的。
解决方案应该是把软件作为一个整体来思考，而不是被狭隘的“操作系统进程”的视角给限制了。构建新的微服务的成本，应该和后台用function启动一个线程没有多大区别。理想的编程语言里，我们有各种各样的function，但是执行机制不同。