甲方、乙方、决策者：企业架构工作中的不同角色与其困境

我最近对于架构的一个体会是，它不应该是一个具体的职位或者被外包的某种服务。架构隐于形，其实是一种设计企业的思想，它不可能被外包给其他企业甚至不能外包给员工代劳，即便被外包也必然是短期的。企业的管理层（尤其是最高管理层）都要掌握这种方法、至少是思维方法。

为什么呢？

因为你做甲方、乙方或自己就是企业决策人是完全不同的。

如果你是甲方人员，在架构工作中困顿的是在企业中不同利益关系中的游走与小心平衡，这些利益相关者包括高层管理者、IT团队、业务部门、外部供应商和合作伙伴等。每个群体都有其独特的利益诉求和关注点，如成本控制、业务敏捷性、技术创新、合规性等等不一而足。其实很多精力都放在这方面了，所以你会发现有些企业里的架构师最终成为了谈判高手，如果这方面薄弱，那建议还是不要从事这类工作，会非常焦虑，这本身就不是个技术工种。

这种情况让他们没太多时间思考架构设计，即便你想的再好，但若各方面关系搞不定，你自己这个饭碗都够呛能保得住，你说这个角色能真正为企业架构负责么？当然利益管理是企业架构中重要的一部分，但不是全部，否则就变成了现状妥协之物。

另外，哪家企业的业务部门都要快速响应市场变化，IT抱怨也没用，架构必须支持业务，大多数普通的架构师也一样（除非是有很High的Power，这种企业很先进，但国内很少，一般都是创新型企业为主），通常需要在有限的时间内忙于决策，而难以进行深入的架构设计和评估，所以这又占据了甲方架构师工作中的很多精力。你说他有时间深入去研究这家企业的架构到底应该如何么？

这种时间压力下往往还会导致架构师在设计中做出妥协，甚至在某些情况下，他们可能不得不牺牲长期的稳定性和可扩展性以换取短期的业务价值。

如果你是乙方人员，那么可发挥的架构设计空间其实会小得多，合同里项目预算就这些，不需要太多思想，干就完了，干完也就完了。即便是你发现有时候架构设计的需求本身就是有问题的，但为了交付你也得做下去，因为对你的评价不是做出多完美的工艺，而是按要求做完滚蛋，你做出的东西属于别人。这个时候考验的是另外一种能力，也即在有限的空间内寻找最佳性价比的架构解决方案、通过高水平的多方沟通以争取共同推动需求的合理化和优化的能力。所以有卓越乙方企业的丰富经验的架构师们的局部专业度往往比较高，因为在这个局部战场里他们身经百战。

比较讨厌的是可能遇到一种极端情况，就你不仅要做好架构专业工作的事儿，还得做好孙子：对方明明不懂、做的不合适，但你不能指出来对方不懂哦，否则你可能会比上一位更早走人。当孙子能做出好架构么？不能，其爷爷的职业就是孙子，孙子更是没有指望。（当然，你在甲方企业里也可能是乙方，你在乙方企业里也可能是甲方。）这种情况下，别考虑架构设计了，走人吧，除非你特别需要打工赚钱。

这是改开以来很多企业染上的“不良老爷习气”，什么是阶级？什么是矛盾？30年的企业治理到底在治什么？成天追求经济效益、追求漂亮数字是不是这个时代的主流和人民的呼声了？

以前在某企业、还是个国企的洗手间发现里面贴的卡通画里讲要善待乙方否则会发生什么什么..当初不理解，后来知道了....那收拾不听话的乙方和下属的手段是真多啊...日后见面有多少刀光剑影是这么来的？之前造的孽，早晚要还。

但如果你是一个企业决策者，并具备架构思维，则如虎添翼，因为你本身就在用先进的业务科技融合的方法在设计你的企业，这也是对现在及未来老板的要求。最典型的如：马化腾、李彦宏、雷军、张一鸣、以及马斯克那些美国企业大佬，本身就是专家，在他们的业务里，已经不强调什么业务与科技融合了，本身从一开始就是长在一起的。但中国大多数做传统业务的企业的老板或要退而求其次，因为在他们的成长历程中没有经历过，若再用过去的经验面对崭新的现在，你说未来的危险大不大？

如一些老企业家交接班是必然的，不管这一批老企业家中怎么批判科技企业，但他们就是存在，如果不是国家干预，传统企业的结局可能会更惨，那能怪这些科技企业么？就像最近热播的《暗夜与黎明》里被抓出来的潜伏者老陈与公安路主任在审讯中的心理博弈中所表达的逻辑是一样的，第一轮老陈完胜：你输了就是输了，你犯的错误导致了一系列公安同志牺牲以及活动失败，不要假设我一定会怜悯你、帮你，因为国共本身就是两条道路。没有任何问题，一语击中路主任的薄弱点，把他心理干崩了，典型的现实不要太残忍。

传统企业的改革是必然的，顺应时代潮流、顺应新用户的特征做变化更是必然的。

企业的战略定位不再仅仅局限于流水线式的产品或服务的提供，而是更多要关注如何利用科技手段创造新的价值点和竞争优势。企业领导者必须具备前瞻性的眼光，洞察未来市场的趋势和变化，并据此制定出具有创新性和可持续性的发展战略。

传统的层级式组织结构逐渐被扁平化、网络化、灵活化的新型组织结构所取代，企业领导者要意识到这一点，要提高企业的运营效率和市场响应速度，激发员工的创新活力和工作热情。为什么企业调整时企业中层是最反感的，因为你会发现在重组中发现了一堆职能重叠的管理者...可有可无，发号施令、跟踪、“指导”，请问如果大多数业务标准化并且上平台了，还需不需要这么多发号施令的管理者？大量的中间管理必然造成组织官僚化。如今组织扁平化走到今天是其进化的必然结果。

要想高效地打造出支撑企业发展的平台能力，有很多功夫要下，不一而足，譬如要对业务领域进行精准的定位和界定，进而基于这一基础，展开业务架构的精细设计，我们今天主要交流这一点。

在业务架构的设计过程中，我们要识别并设计“子域”、“领域对象”以及“领域事件”这三个核心要素。每一个子域都是业务领域中的一部分，它们如同拼图般紧密相连，构成了企业业务的全貌；领域对象则是业务活动中不可或缺的实体，它们承载着业务流程的关键信息；而领域事件则是业务流程中的关键时刻点，它们的发生往往意味着业务状态的重大转变。

领域设计者与软件开发者的工作关系如下：

这个图其实没画完，DBE的后面是业务架构师角色。

以某家智慧零售业务集团企业为例，在业务架构的设计过程中，我们聚焦于领域战略层面的模型框架勾勒。“纠结技术细节”是架构设计的大忌，很多技术专家并不适合做业务架构师的原因就在这里，你一纠结技术细节就掉进去了。术业有专攻，从技术专家转变成架构师，本身就是一个转型。

我个人非常不喜欢用虚无缥缈或摸凌两可的曲线图来去设计和呈现架构。譬如这种：

这种图你可以用来当脑图作为帮助澄清的过程办法，但不能作为一个清晰架构的定义。你会发现当你接触的业务复杂指数翻倍增长的时候，你根本不可能通过这种人为的方式来勾勒。元模型要足够精简并高度结构化。

如果从语义上你就无法准确定义，那么断然设计结果会存在真空地带，这就如一个桥梁架构某一个桥墩受力图看起来差不多、大约是那么回事，但是一旦真的这么设计出来、你就会发现很多因素的前期考虑和设计不够solid，譬如，制动力是多少？温度影响力是多少？可能的船舶撞击力是多少？如果这些都是模糊的，其极限不知在何处，你设计出来的东西能让人放心么？

先说第一个，子域是对问题域的澄清和划分，也是资源投入优先级的重要参考。

在划分子域时，我们关注每个子域所解决的独立业务价值问题。通过疑问句的方式，我们可以进一步澄清和分析子域的业务需求。例如，“如何进行库存管理？”就是一个典型的子域问题。

我们将解决同一业务问题（这个问题背后应该是清晰的领域定位，而不是通过问题来划定范围，那是非常不靠谱的）的限界上下文划在一起。根据子域的类型（譬如，核心域、支撑域），我们结合业务实际来确定每个子域的资源投入优先级。核心域是业务的核心竞争力所在，需要投入最优势的资源进行设计和开发。支撑域解决支撑核心域运作的问题，虽然重要程度不如核心域，但也需要专门的团队进行定制开发。最后，要有一个通用域，可采用现成的解决方案，通过购买或简单修改的方式即可使用。企业的通用域需要被统一管理。

再说第二个，领域对象。

领域对象是业务的高度抽象，是系统和业务之间的核心联系。它们封装和承载了业务逻辑，是系统设计的基础。领域对象通常包括在领域事件中出现的名词、现实中可见的事物以及未来可能抽象出来的业务概念。

在识别领域对象时，须基于领域事件的结果进行。对于每一个领域事件，快速识别出与其最相关的业务概念，并将其以名词形式贴出。接着，检查领域名词和领域事件在概念和粒度上的一致性，并统一语言以消除二义性。在识别过程中，我们不断迭代和优化，以确保领域对象的准确性和完整性。

国内一直把object这个东西直接翻译成对象，其实如不仔细看英文原文，对于读者来说是一个非常大的困扰甚至误导，我自己就困惑了很久，其实这就是一个软硬智能体的早期概念形态罢了，存在的形式未来是否是实体都不太重要了，只要概念形态存在无外乎是找个机器人载体。

最后说领域事件的识别。

领域事件是业务上真实发生且对系统产生重要影响的事件。这已经有个基本前提，也即业务是通过科技手段实现的了。这些事件是业务逻辑的触发器，也是系统实现的重要基础。通过领域事件，可以追溯过去发生的业务活动，因为这些事件都会以某种形式被记录下来。例如，“用户地址已更新”或“订单已发货”等事件，都是业务过程中不可或缺的一部分。

为了识别领域事件，通常采用“事件风暴（Event Storming）”的方法。这一方法须邀请业务专家和技术专家共同参与，通过工作坊的形式来梳理和分析业务场景中的事件。首先需要明确起始事件和结束事件。例如，起始事件可能是“顾客进店”或“顾客在线浏览商品”，而结束事件则可能是“顾客完成支付”或“顾客退货”。

接着，根据业务场景的复杂度，选择从时间线开始梳理事件，并补充和完善领域事件。譬如，“顾客选择商品”、“顾客加入购物车”、“顾客提交订单”等。

在梳理过程中，使用“规则”来抽象复杂的分支条件，以降低系统的复杂性。例如，对于“顾客是否满足优惠券使用条件”这一复杂判断，将其抽象为一个规则，并在事件流中明确标注。这样，当系统运行时，只需根据规则来判断是否执行相应的操作，而无需处理复杂的逻辑判断。说白了就是写一段代码封装起来，到了这个环节就启用，if then else...有个标准的规则判断，而不是每到这个环节，不同IT的研发负责者都要写一段自己理解的代码。

团队可使用贴纸或白板等工具将事件可视化，以便更好地理解和分析。最后，通过逆向检查的方式，确保事件流的逻辑合理性。

我们将此三者做具体定义更便于分析：

1 子域（Subdomains）

商品管理子域（Commodity Management Subdomain）：作为业务架构的核心组成部分，该子域负责商品的全生命周期管理，涵盖商品的上架、下架、库存监控、价格策略调整等关键活动。它如同业务架构中的中枢节点，与订单处理、客户管理等子域形成紧密集成，确保商品信息的准确性和一致性。

订单处理子域（Order Processing Subdomain）：该子域专注于处理从客户下单至商品出库的全链条流程，包括订单创建、支付验证、库存预留与扣减、物流分配与跟踪等。它与商品管理子域紧密协作，确保订单中商品信息的实时同步与准确性。

客户管理子域（Customer Management Subdomain）：此子域致力于管理客户的个人信息、购买历史、偏好设置等关键数据，以提供个性化的购物体验与精准的营销活动。它与订单处理子域进行数据交换，可深入分析客户的购买行为，为定制化服务提供数据支撑。

2 领域实体（Domain Entities）/领域对象（Domain Objects）

商品实体（Commodity Entity）：在商品管理子域中，商品实体作为核心实体，包含商品的唯一标识符（ID）、名称、描述、价格、库存数量、分类等关键属性。它作为连接订单处理与客户管理子域的桥梁，确保商品信息的准确传递。

订单实体（Order Entity）：在订单处理子域中，订单实体记录着客户购买行为的全过程，包括订单ID、客户ID、商品列表（含商品ID、数量等）、支付状态、物流信息等关键属性。它作为业务流程中的关键实体，驱动着库存扣减、物流分配等后续流程。

客户实体（Customer Entity）：在客户管理子域中，客户实体承载着客户的个人信息与购买历史，包括客户ID、姓名、联系方式、购买记录、偏好设置等关键属性。它作为个性化服务与营销的基础，为提升客户满意度与忠诚度提供数据支持。

3 领域事件（Domain Events）

商品上架事件（Commodity Listing Event）：当商品管理子域中的商品成功上架时，触发此事件。它标志着商品状态的转变，从待上架状态转变为可销售状态，同时触发相关通知与营销活动。

订单支付成功事件（Order Payment Success Event）：当订单处理子域中的订单支付成功时，触发此事件。它标志着订单状态的转变，从待支付状态转变为已支付状态，并触发后续的库存扣减、物流分配等流程。

客户购买偏好更新事件（Customer Preference Update Event）：当客户管理子域中的客户购买偏好发生变化时，触发此事件。它标志着客户状态的转变，为后续的个性化营销与服务提供数据基础，促进客户忠诚度的提升。