应用架构之道-让上帝的归上帝，凯撒的归凯撒

分离业务逻辑和技术细节

架构

什么是架构？

关于架构这个概念很难给出一个明确的定义，也没有一个标准的定义。

硬是要给一个概述，我认为架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。

架构始于建筑，是因为人类发展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作。

为什么需要架构？

有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件都需要设计和架构。

我很喜欢《系统架构：复杂系统的产品设计与开发》里面的一句话：结构良好的创造活动要优于毫无结构的创造活动。

与之相对应的，现在很多敏捷思想提倡no design，只要work就好。期待好的架构可以在迭代中自然涌现。这个想法有点太理想化了，在现实中，只要能work的代码，工程师是很少有动力去重构和优化的。

架构师的职责

作为架构师，我们最重要的价值应该是“化繁为简”。但凡让事情变得更复杂，让系统变得更晦涩难懂的架构都是值得商榷的。

架构师的工作就是要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，使哪些系统不再那么难懂。我们应该努力构建易懂的架构，使得在系统上工作的其他人员（例如设计者、实现者、操作员等）可以较为容易地理解这个系统。

软件架构

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。

软件架构的核心价值应该只围绕一个核心命题：控制复杂性。他并不意味着某个特定的分层结构，某个特定的方法论（贫血、DDD等）。

软件架构分类

在介绍应用架构之前，我们先来看一下软件架构的分类。

随着互联网的发展，现在的系统要支撑数亿人同时在线购物、通信、娱乐的需要，相应的软件体系结构也变得越来越复杂。软件架构的含义也变得更加宽泛，我们不能简单地用一个软件架构来指代所有的软件架构工作。按照我个人理解，我将软件架构划分为：

业务架构：由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。例如，阿里巴巴在没有中台部门之前，每个业务部门的技术架构都是烟囱式的，淘宝、天猫、飞猪、1688等各有一套体系结构。而后，成立了共享平台事业部，打通了账号、商品、订单等体系，让商业基础实施的复用成为可能。

应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。

分布式系统架构：分布式系统基本是稍具规模业务的必选项。它需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在CAP（Consistency，Availability，Partition tolerance）之间进行权衡。

数据架构：对于规模大一些的公司，数据治理是一个很重要的课题。如何对数据收集、数据处理提供统一的服务和标准，是数据架构需要关注的问题。其目的就是统一数据定义规范，标准化数据表达，形成有效易维护的数据资产，搭建统一的大数据处理平台，形成数据使用闭环。

物理架构：物理架构关注软件元件是如何放到硬件上的，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。

运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

典型应用架构

分层架构

分层是一种常见的根据系统中的角色（职责拆分）和组织代码单元的常规实践。常见的分层结构如下图所示：

CQRS

CQS(Command Query Separation，命令查询分离)最早来自于Betrand Meyer（Eiffel语言之父，OCP提出者）提出的概念。其基本思想在于，任何一个对象的方法可以分为两大类：

• 命令(Command):不返回任何结果(void)，但会改变对象的状态。
• 查询(Query):返回结果，但是不会改变对象的状态，对系统没有副作用。
  

六边形架构

六边形架构是Alistair Cockburn在2005年提出，解决了传统的分层架构所带来的问题，实际上它也是一种分层架构，只不过不是上下，而是变成了内部和外部（如下图所示）。

六边形架构又称为端口-适配器架构，这个名字更容器理解。六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。

适配器分为两种类型（如下图所示），左侧代表 UI 的适配器被称为主动适配器（Driving Adapters），因为是它们发起了对应用的一些操作。而右侧表示和后端工具链接的适配器，被称为被动适配器（Driven Adapters），因为它们只会对主适配器的操作作出响应。

洋葱圈架构

洋葱架构与六边形架构有着相同的思路，它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来，避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换，可以一定程度地避免技术、工具或者供应商锁定。

不同的是洋葱架构还告诉我们，企业应用中存在着不止两个层次，它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次（Application，Domain Service，Domain model，Infrastructure等）

另外，它还有着脱离真实基础设施和传达机制应用仍然可以运行的便利，这样可以使用 mock 代替它们方便测试。

在洋葱架构中，明确规定了依赖的方向：

• 外层依赖内层；
• 内层对外层无感知。

COLA应用架构

COLA架构是我团队自主研发的应用架构，目前已经开源（ https://github.com/alibaba/COLA ）。在COLA的设计中，我们充分汲取了经典架构的优秀思想。除此之外，我们补充了规范设计和扩展设计，并且使用Archetype的方式，将架构固化下来，以便可以快速的在开发中使用。

分层设计

COLA的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分成应用层、领域层和基础实施层。如下图所示，左边是传统的分层架构，右边是COLA的分层架构。

其每一层的作用范围和含义如下：
1）展现层（Presentation Layer）：负责以Rest的格式接受Web请求，然后将请求路由给Application层执行，并返回视图模型（View Model），其载体通常是DTO（Data Transfer Object）；

2）应用层（Application Layer）：主要负责获取输入，组装上下文，做输入校验，调用领域层做业务处理，如果需要的话，发送消息通知。当然，层次是开放的，若有需要，应用层也可以直接访问基础实施层；

3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Entities）的函数对外部提供业务逻辑的计算和处理；

4）基础实施层（Infrastructure Layer）主要包含Tunnel（数据通道）、Config和Common。这里我们使用Tunnel这个概念来对所有的数据来源进行抽象，这些数据来源可以是数据库（MySQL，NoSql）、搜索引擎、文件系统、也可以是SOA服务等；Config负责应用的配置；Common是通用的工具类。

扩展设计

对于只有一个业务的简单场景，对扩展性的要求并不突出，这也是为什么扩展设计常被忽略的原因，因为我们大部分的系统都是从单一业务开始的。但是随着业务场景越来越复杂，代码里面开始出现大量的if-else逻辑。此时除了常规的策略模式以外，我们可以考虑在架构层面提供统一的扩展解决方案。

在扩展设计中，我们提炼出两个重要的概念，一个是业务身份，另一个是扩展点。

业务身份是指业务在系统唯一标识一个业务或者一个场景的标志。在具体实现中，我们使用BizCode来表示业务身份，其中BizCode采用类似Java包名命名空间的方式。例如，我们可以用“ali.tmall”表示阿里天猫业务，用“ali.tmall.car” 表示阿里天猫的汽车业务，而用"ali.tmall.car.aftermarket"代表这是阿里天猫的汽车业务的后市场场景。

每个业务或者场景都可以实现一个或多个扩展点（ExtensionPoint），也就是说一个业务身份加上一个扩展点，可以唯一地确定一个扩展实现（Extension）。而这个业务身份和扩展点的组合，我们将其称之为扩展坐标（ExtensionCoordinate），如下图所示。

这样，通过业务身份+扩展点，我们就可以从框架层面实现对不同租户，不同业务，不同场景的扩展定制了。整个阿里业务中台正是基于这个思想，实现的多业务支撑的。

规范设计

任何事物都是规则性和随机性的组合。规范的意义就在于我们可以将规则性的东西固化下来，尽量减少随心所欲带来的复杂度，一致性可以降低系统复杂度。从命名到架构皆是如此，而架构本身就是一种规范和约束，破坏这个约束，也就破坏了架构。

COLA制定了一些列的规范：包括组件（Module）结构、包（Package）结构、命名等。

比如对于组件，我们要求使用COLA的应用都应该遵循如下图所示的组件划分：

COLA架构总览

在架构思想上，COLA主张像六边形架构那样，使用端口-适配器去解耦技术细节；主张像洋葱圈架构那样，以领域为核心，并通过依赖倒置反转领域层的依赖方向。最终形成如下图所示的组件关系。

换一个视角，从COLA应用处理响应一个请求的过程来看。COLA使用了CQRS来分离命令和查询的职责，使用扩展点和元数据来提升应用的扩展性。整个处理流程如下图所示：

应用架构的核心

纵观上面介绍的所有应用架构，我们可以发现一个共同点，就是“核心业务逻辑和技术细节分离”。

是的，六边形架构、洋葱圈架构、以及COLA架构的核心职责就是要做核心业务逻辑和技术细节的分离和解耦。

试想一下，业务逻辑和技术细节糅杂在一起的情况，所有的代码都写在ServiceImpl里面，前几行代码是做validation的事，接下来几行是做convert的事，然后是几行业务处理逻辑的代码，穿插着，我们需要通过RPC或者DAO获取更多的数据，拿到数据后，又是几行convert的代码，在接上一段业务逻辑代码，然后还要落库，发消息…等等。

再简单的业务，按照上面这种写代码的方式，都会变得复杂，难维护。

因此，我认为应用架构的核心使命就是要分离业务逻辑和技术细节。让核心业务逻辑可以反映领域模型和领域应用，可以复用，可以很容易被看懂。让技术细节在辅助实现业务功能的同时，可以被替换。

最后我们发现，应用架构的道就是：“让上帝的归上帝，凯撒的归凯撒。”

复杂业务代码要怎么写

了解我的人都知道，我一直在致力于应用架构和代码复杂度的治理。

这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景，如何在架构和代码层面进行应对，是一个新课题。针对该命题，我进行了比较细致的思考和研究。结合实际的业务场景，我沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家。

我相信，同样的方法论可以复制到大部分复杂业务场景。

一个复杂业务的处理过程

业务背景

简单的介绍下业务背景，零售通是给线下小店供货的B2B模式，我们希望通过数字化重构传统供应链渠道，提升供应链效率，为新零售助力。阿里在中间是一个平台角色，提供的是Bsbc中的service的功能。

在商品域，运营会操作一个“上架”动作，上架之后，商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一，因此涉及很多的数据校验和关联操作。

针对上架，一个简化的业务流程如下所示：

过程分解

像这么复杂的业务，我想应该没有人会写在一个service方法中吧。一个类解决不了，那就分治吧。

说实话，能想到分而治之的工程师，已经做的不错了，至少比没有分治思维要好很多。我也见过复杂程度相当的业务，连分解都没有，就是一堆方法和类的堆砌。

不过，这里存在一个问题：即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中，类似的分解手段至少有3套以上，有自制的流程引擎，有依赖于数据库配置的流程处理：

本质上来讲，这些辅助手段做的都是一个pipeline的处理流程，没有其它。因此，我建议此处最好保持KISS（Keep It Simple and Stupid），即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。

除非你的应用有极强的流程可视化和编排的诉求，否则我非常不推荐使用流程引擎等工具。第一，它会引入额外的复杂度，特别是那些需要持久化状态的流程引擎；第二，它会割裂代码，导致阅读代码的不顺畅。大胆断言一下，全天下估计80%对流程引擎的使用都是得不偿失的。

回到商品上架的问题，这里问题核心是工具吗？是设计模式带来的代码灵活性吗？显然不是，问题的核心应该是如何分解问题和抽象问题，知道金字塔原理的应该知道，此处，我们可以使用结构化分解将问题解构成一个有层级的金字塔结构：

按照这种分解写的代码，就像一本书，目录和内容清晰明了。

以商品上架为例，程序的入口是一个上架命令（OnSaleCommand）, 它由三个阶段（Phase）组成。

@Command
public class OnSaleNormalItemCmdExe {

    @Resource
    private OnSaleContextInitPhase onSaleContextInitPhase;
    @Resource
    private OnSaleDataCheckPhase onSaleDataCheckPhase;
    @Resource
    private OnSaleProcessPhase onSaleProcessPhase;

    @Override
    public Response execute(OnSaleNormalItemCmd cmd) {
        
        OnSaleContext onSaleContext = init(cmd);
        
        checkData(onSaleContext);

        process(onSaleContext);

        return Response.buildSuccess();
    }

    private OnSaleContext init(OnSaleNormalItemCmd cmd) {
        return onSaleContextInitPhase.init(cmd);
    }

    private void checkData(OnSaleContext onSaleContext) {
        onSaleDataCheckPhase.check(onSaleContext);
    }

    private void process(OnSaleContext onSaleContext) {
        onSaleProcessPhase.process(onSaleContext);
    }
}

每个Phase又可以拆解成多个步骤（Step），以OnSaleProcessPhase为例，它是由一系列Step组成的：

@Phase
public class OnSaleProcessPhase {

    @Resource
    private PublishOfferStep publishOfferStep;
    @Resource
    private BackOfferBindStep backOfferBindStep;
    //省略其它step

    public void process(OnSaleContext onSaleContext){
        SupplierItem supplierItem = onSaleContext.getSupplierItem();

        // 生成OfferGroupNo
        generateOfferGroupNo(supplierItem);
       
       // 发布商品
        publishOffer(supplierItem);

        // 前后端库存绑定 backoffer域
        bindBackOfferStock(supplierItem);

        // 同步库存路由 backoffer域
        syncStockRoute(supplierItem);

        // 设置虚拟商品拓展字段
        setVirtualProductExtension(supplierItem);

        // 发货保障打标 offer域
        markSendProtection(supplierItem);

        // 记录变更内容ChangeDetail
        recordChangeDetail(supplierItem);

        // 同步供货价到BackOffer
        syncSupplyPriceToBackOffer(supplierItem);

        // 如果是组合商品打标，写扩展信息
        setCombineProductExtension(supplierItem);

        // 去售罄标
        removeSellOutTag(offerId);

        // 发送领域事件
        fireDomainEvent(supplierItem);
        
        // 关闭关联的待办事项
        closeIssues(supplierItem);
    }
}

看到了吗，这就是商品上架这个复杂业务的业务流程。需要流程引擎吗？不需要，需要设计模式支撑吗？也不需要。对于这种业务流程的表达，简单朴素的组合方法模式（Composed Method）是再合适不过的了。

因此，在做过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的阶段（Phase）和步骤（Step）上。

过程分解后的两个问题

的确，使用过程分解之后的代码，已经比以前的代码更清晰、更容易维护了。不过，还有两个问题值得我们去关注一下：

1、领域知识被割裂肢解

什么叫被肢解？因为我们到目前为止做的都是过程化拆解，导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程，知识没有沉淀。

相同的业务逻辑会在多个Use Case中被重复实现，导致代码重复度高，即使有复用，最多也就是抽取一个util，代码对业务语义的表达能力很弱，从而影响代码的可读性和可理解性。

2、代码的业务表达能力缺失

试想下，在过程式的代码中，所做的事情无外乎就是取数据–做计算–存数据，在这种情况下，要如何通过代码显性化的表达我们的业务呢？ 说实话，很难做到，因为我们缺失了模型，以及模型之间的关系。脱离模型的业务表达，是缺少韵律和灵魂的。

举个例子，在上架过程中，有一个校验是检查库存的，其中对于组合品（CombineBackOffer）其库存的处理会和普通品不一样。原来的代码是这么写的：

boolean isCombineProduct = supplierItem.getSign().isCombProductQuote();

// supplier.usc warehouse needn't check
if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) {
// quote warehosue check
if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) {
    throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！");
}
// inventory amount check
Long sellableAmount = 0L;
if (!isCombineProduct) {
    sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList());
} else {
    //组套商品
    OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId());
    if (backOffer != null) {
        sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale();
    }
}
if (sellableAmount < 1) {
    throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，实仓库存必须大于0才能发布，请确认已补货.
[id:" + supplierItem.getId() + "]");
}
}

然而，如果我们在系统中引入领域模型之后，其代码会简化为如下：

if(backOffer.isCloudWarehouse()){
    return;
}

if (backOffer.isNonInWarehouse()){
    throw new BizException("亲，不能发布Offer，请联系仓配运营人员，建立品仓关系！");
}

if (backOffer.getStockAmount() < 1){
    throw new BizException("亲，实仓库存必须大于0才能发布，请确认已补货.
[id:" + backOffer.getSupplierItem().getCspuCode() + "]");
}  

有没有发现，使用模型的表达要清晰易懂很多，而且也不需要做关于组合品的判断了，因为我们在系统中引入了更加贴近现实的对象模型（CombineBackOffer继承BackOffer），通过对象的多态可以消除我们代码中的大部分的if-else。

过程分解+对象模型

通过上面的案例，我们可以看到有过程分解要好于没有分解，过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case，如果采用过程分解+对象模型的方式，最终我们会得到一个如下的系统结构：

写复杂业务的方法论

通过上面案例的讲解，我想说，我已经交代了复杂业务代码要怎么写：即自上而下的结构化分解+自下而上的面向对象分析。

接下来，让我们把上面的案例进行进一步的提炼，形成一个可落地的方法论，从而可以泛化到更多的复杂业务场景。

上下结合

所谓上下结合，是指我们要结合自上而下的过程分解和自下而上的对象建模，螺旋式的构建我们的应用系统。这是一个动态的过程，两个步骤可以交替进行、也可以同时进行。

这两个步骤是相辅相成的，上面的分析可以帮助我们更好的理清模型之间的关系，而下面的模型表达可以提升我们代码的复用度和业务语义表达能力。

其过程如下图所示：

使用这种上下结合的方式，我们就有可能在面对任何复杂的业务场景，都能写出干净整洁、易维护的代码。

能力下沉

一般来说实践DDD有两个过程：

1. 套概念阶段

了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bonded Context，Repository等等这些概念。跟进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。

2. 融会贯通阶段

术语已经不再重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。

大体上而言，我大概是在1.7的阶段，因为有一个问题一直在困扰我，就是哪些能力应该放在Domain层，是不是按照传统的做法，将所有的业务都收拢到Domain上，这样做合理吗？说实话，这个问题我一直没有想清楚。

因为在现实业务中，很多的功能都是用例特有的（Use case specific）的，如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反，这种收拢会导致Domain层的膨胀过厚，不够纯粹，反而会影响复用性和表达能力。

鉴于此，我最近的思考是我们应该采用能力下沉的策略。

所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制让把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了。

注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程

通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。

下沉的过程如下图所示，假设两个use case中，我们发现uc1的step3和uc2的step1有类似的功能，我们就可以考虑让其下沉到Domain层，从而增加代码的复用性。

指导下沉有两个关键指标：代码的复用性和内聚性。

复用性是告诉我们When（什么时候该下沉了），即有重复代码的时候。内聚性是告诉我们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（因为Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另一个是Domain的Model这个是最细粒度的复用）。

比如，在我们的商品域，经常需要判断一个商品是不是最小单位，是不是中包商品。像这种能力就非常有必要直接挂载在Model上。

public class CSPU {
    private String code;
    private String baseCode;
    //省略其它属性

    /**
     * 单品是否为最小单位。
     *
     */
    public boolean isMinimumUnit(){
        return StringUtils.equals(code, baseCode);
    }

    /**
     * 针对中包的特殊处理
     *
     */
    public boolean isMidPackage(){
        return StringUtils.equals(code, midPackageCode);
    }
}

之前，因为老系统中没有领域模型，没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的，至少在第一眼看到的时候，是完全不知道什么意思。

业务技术要怎么做

写到这里，我想顺便回答一下很多业务技术同学的困惑，也是我之前的困惑：即业务技术到底是在做业务，还是做技术？业务技术的技术性体现在哪里？

通过上面的案例，我们可以看到业务所面临的复杂性并不亚于底层技术，要想写好业务代码也不是一件容易的事情。业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。

业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如，如果你需要去开发Pandora，你就要对Classloader有更加深入的了解才行。

但是，不管是业务技术还是底层技术人员，有一些思维和能力都是共通的。比如，分解问题的能力，抽象思维，结构化思维等等。

用我的话说就是：“做不好业务开发的，也做不好技术底层开发，反之亦然。业务开发一点都不简单，只是我们很多人把它做“简单”了

因此，如果从变化的角度来看，业务技术的难度一点不逊色于底层技术，其面临的挑战甚至更大。因此，我想对广大的从事业务技术开发说：沉下心来，夯实自己的基础技术能力、OO能力、建模能力… 不断提升抽象思维、结构化思维、思辨思维… 持续学习精进，写好代码。我们可以在业务技术岗做的很”技术“！。

人人都是架构师：架构是一种能力，不是头衔！

架构是一种能力，它不是头衔。 换句话说，我们需要具备架构能力，但不一定要成为架构师。就像邓公，他被称为改革开放的总设计师，但他不是设计师。

既然这样，那我们还需要架构师吗？还需要架构部门吗？

我给出的答案是：不需要，因为每个人都应该是架构师。

为什么架构师不work

在来阿里之前，我是在eBay的payments部门工作，当时有一个架构师叫Scott，所有的设计和方案都需要获得他的approve才能通过，结果他成了整个团队的bottleneck，很多事情都block在他那个地方。

工程师很难受，光是给他介绍业务和系统设计，就需要花费了大量的时间讨论（因为时差原因，经常一个讨论要一个星期才会有定论）。他也不容易，要去理解每个系统的结构和业务细节，已经累成狗。

效率低下尚且不说，这样的折腾最后带来了什么益处呢？说实话，我现在回想起来，除了几个变量命名我觉得Scott说的比较有道理以外，其它还真没什么更有价值的东西了。

这里我想主要问题是因为Scott不在执行团队内部，他不了解细节，所以也很难给出有价值的输入。很多东西，我们认为“他不懂”，也就是他的方案不能让我们信服，自然，合作起来就很困难。

很多人喜欢拿建筑架构和软件架构做类比，认为既然建筑需要建造师，那么软件也应该需要架构师。Too simple, too naive!

其实，二者除了都需要有图纸，都有艺术的成分之外，并没有多少共同之处。

首先，建筑和软件不同。建筑的标准性、确定性要比软件高的多，而软件的灵活性简直是没有边界的，任何一个function都可以有无数的实现方式，没有定式。因此，软件架构图的约束力，要远远低于建筑图纸的约束力。建筑如果不按照设计来，你就不能实现其功能。而软件设计文档和代码，完全可以是两个平行宇宙。

其次，建筑工人和程序员不同。程序员的工作绝对不仅仅是“搬砖”这么简单，软件设计是一个充满挑战的创造性工作。它需要对各种微妙之处进行权衡，只有深入其中，hands-on coding，才能真正的发现问题。因此，飘在开发团队之上，指手画脚的PPT架构师，注定是很难成功的。

为什么架构部门不work

如果说架构师是轻量级解决方案的话，那么，还有一个“大规模杀伤性武器”就是设立一个专门的架构组织。

几年前的B2B就有一个这样的架构组织。我记得在当年的“架构图”KO会议上，当时的负责人要求我们画架构图，我就质问他这个架构组存在的意义是什么？如果只是画架构图，给老板当ppt用的话，这个图我不愿意画。我当时还严厉的说了句名言——KO不一定要Kick Off，也可以是Kick Out。不止于此，而后我又“上书”到当时B2B的CTO，再然后... 随着CTO的调离，架构负责人的离职，也就没有然后了...

实际上，“架构图”这种务虚活动还好，虽然无用，但也构不成杀伤。真正构成杀伤的是架构组织不甘无为，挖空心思要“做事情”。

可以说，在业务技术部门，架构组这种“想做事”的行为是很危险的，事情越大，杀伤力越大。

何出此言？我们不妨先来看一下，在业务技术部门，架构组织能做什么。

1. 业务架构？我是营销域的，是订单域的，是商品域的，是供应链域的... 你架构组告诉我，你对业务领域，业务流程，业务细节的理解比PD、运营、工程师更懂？恐怕难，一个合格的PD应该能做好业务领域的抽象和业务流程的抽象，至于细节，好像没有人比一线开发更懂。架构组，卒！

2. 应用架构？需求相对清晰之后，我一个在应用架构领域尚且有一些影响力的TL在和团队讨论边界划分，设计方案的时候，时常会争论不休。你一个架构组的“外人”想来指手画脚？呵呵，你这是有多低估程序员的自尊心啊。架构组，卒！

3. 技术架构？好吧，那我们架构组回归技术本身，做点纯技术的事情总可以吧。对不起，但凡有点价值的技术中间件，已经有中间件团队在做了。还记得，ICBU架构组搞的Hilton容器和AE架构组（中间件团队）的“我行我素”使用SpringBoot吗。这种重复造轮子完全没有必要。在云原生成熟之前，PandoraBoot就是最好的解决方案。架构组，带着整个BU一起——卒！

在此我想稍微提一下支付宝的中间件团队（架构部门？），我不知道历史，也许TecFin的确是有其特殊性。但是，从整个集团角度来说，我认为统一的技术中台，应该是更好的做法。

对一个企业来说，也许在某个特殊阶段，的确需要实体架构组织去保障落实架构工作。

但大部分情况下，特别是在技术体系已经相对完备的情况下。比如在阿里，业务技术部门，最好是不要在BU内设立专门的架构组织，相信我，在我的职业生涯中，看到过很多业务技术部门设立的技术架构组织案例，基本都是以失败而告终。

人人都是架构师

架构师不行，架构部门也不行。那架构的事情谁来做呢？看一下你座位左边的，再看一下你座位右边的，再看一下你主管.... 别看了，他们是要做，你自己也要做，人人都是架构师。

首先，让我们来看一下什么是架构能力，我认为广义的架构能力，应该是一套分析问题、解决问题的方法论。它需要你具备洞察问题本质要素，理清要素之间的关系，以及制定相应策略的能力。

从这个视角出发，我认为架构能力就是核心竞争力，每个工程师都应该具备一定的架构能力，人人都应该是架构师。 怎么理解？

1. 作为技术一线员工，也许你的工作时间并不长，架构能力相对较弱，没有捷径，学习学习再学习，成长成长再成长，架构作为能力是可以习得的，没那么高深。

2. 作为技术团队Leader，你必须要具备一定的架构能力了，不管是业务架构还是应用架构。TL都应该具备能发现问题里的本质要素，以及理清要素之间关系的能力。如果你已经是一名TL，然而架构能力还比较欠缺，则需要尽快去补足。不足没有关系，有关系的是停止了学习和成长。就像怀素说的，很多后劲不足的人主要是过早的停止了学习和成长，你的能力应该是围绕着你的层级震荡的，这个震荡范围偏差不会太大，迟早会归于一个相对合理的区间。

3. 作为CTO（没吃过猪肉，但看过猪跑），CTO没得选了，必须是一个非常、非常优秀的架构师才行。你不仅要熟悉业务架构，精通技术架构。更重要的是因为屁股问题（康威定律），你还要去设计组织架构，让生产关系适应生产力的发展。唯有如此，技术才能稳定高效的支撑业务发展。

听说，腾讯没有CTO，所以他们每个BU都有一套自己的技术栈和中间件，大家各自为政。

如果上图对腾讯的架构描述属实的话，我觉得最好他们还是要有一个CTO比较好。因为很明显，对于通用的技术解决方案，比如大数据处理，技术中间件。没必要重复造轮子，复用很明显是更加科学的做法。

在这一点上，如下图所示，我认为阿里无疑是走在腾讯前面的。其中，数据中台和技术中台，我认为是阿里做的最好，也是最NB的地方。至于业务中台为什么旁边飘着一朵小乌云呢，这是因为业务的抽象复用要比技术的抽象复用难的多的多的多，不同业务面临的业务问题的差异是巨大的，而不同业务面临的技术问题相对业务问题，要稳定的多。我想，这也是为什么技术中台已经成功，业务中台还在探索的原因吧。

如何践行

最后，分享一下我是如何在团队做“架构师”的。

一方面，我会不遗余力的培养团队成员的架构能力，我会不断的和他们探讨系统的边界是否合理，模型抽象是否合理，流程抽象是否合理，模块设计是否合理。并要求他们说清楚设计背后的思考和理念是什么，然后用我自己的方法论、思考和他们去碰撞，这样反复进行，我和团队都会有所成长。

另一方面，我会hands-on coding，参与核心业务逻辑的编码工作，这点很重要。一定要深入代码细节中去做架构，因为很多问题只有在coding的过程中才会暴露出来。另外，无谓的讨论是低效的，验证架构是否合理的方式，就是结合业务场景，写代码去验证。设计是否合理，是否优雅，在coding的过程中，便能获得很好的反馈。我不止一次，在写代码的过程中，去重构原来的设计，甚至是完全推翻重来。

总而言之，架构作为一种能力，作为我们工程师的核心成长目标，值得我们去孜孜不倦的追求。而架构师作为一个职位，在大部分情况下，它就是个“呵呵”。

from:

https://blog.csdn.net/significantfrank/article/details/94593620;

https://blog.csdn.net/significantfrank/article/details/98087611;

https://blog.csdn.net/significantfrank/article/details/106798841