分层是软件设计中普遍存在的理念，从某种意义上看，架构的本质就是分层。目前业界有多种架构分层方法，这些分层方法彼此侧重的视角差异大，在一些概念的命名上比较随意，有种百花齐放的味道，这带来的问题也很明显，由于缺乏统一标准，导致不同圈子、不同行业、不同公司的人在合作、沟通时存在较高的成本。今天来总结下笔者看到的几种当下最常见的分层方法。
DDD分层
先说DDD分层架构，由于有完整的理论体系支撑，这种分层方法争议本身不大。DDD提出了应用层、领域层、基础设施层。DDD分层架构讨论的范畴一般是针对单个系统。
-
应用层（application layer）：重点关注产品的应用场景，是离用户使用操作最近的那部分，我认为其复杂性和变化性是较高的。
-
领域层（domain layer）：重点关注业务实体、业务核心领域规则，对于一个成熟的产品而言，该层是系统中相对稳定、也最核心的部分。
-
基础设施层（infra layer）：这层是最好理解的，就是一个系统的通用基础服务，和业务相关性不强，是最底层的部分。
中台分层
中台分层架构，是随着近些年中台概念兴起的一种分层思想，由于每个人对中台的理解有较大的gap，导致这种分层架构有较大的理解成本和一定争议。这种分层方法一般会分为前台、中台、后台，有时还会包含原子能力层。中台分层架构讨论的范畴一般是针对由多个系统组成的复杂度较高的产品。
-
前台：为产品的最终客户提供服务的系统功能模块，一般是各种触达端，如小程序、app客户端、pc站点等。
-
中台：中台是为多个产品线和业务场景提供可复用能力的部分，中台一般提供的是相对粗粒度的产品能力，而非原子能力。
-
后台：为企业的内部人员或管理员使用的功能模块，提供后台的运营支撑、系统配置能力。
-
原子能力：中台和后台，提供的是相对粗粒度的能力，那支撑它们运转的是底层的一些原子能力。
标准分层（伪DDD）
这种分层方法是我见的最多的，也是理解成本最低、争议最小的。一把会将分为三层：业务层、核心层、基础层。我认为这种分层方法是山寨版的DDD，其核心思想和DDD非常相似。由于DDD落地有一定的学习成本，在不少团队用的就是这种方法。这种分层架构讨论的范畴一般是单个系统。
-
业务层（biz）：面向产品的业务场景，封装相对粗粒度的业务能力，比如下单、改单等操作场景；
-
核心层（core）：产品中最重要的部分，一般是核心的领域逻辑或具备一定复用性的业务能力，比如核心的订单模型、订单状态机控制、订单数据版本等；
-
基础层（common）：在一个系统中属于基础支撑的部分，例如电商系统中的商品模块等；或者通用服务，如消息触达的工具类等。
基于粒度分层
这种分层架构在有些产品逻辑比较复杂的场景下会使用，它主要是关注封装的服务的粒度。一般分为三层：聚合层、原子能力层、基础层。这种分层架构一般针对的是一个或多个系统。
1.聚合层：封装相对粗粒度的服务，如果站在给前端产品提供定制化能力的视角，有些业务把BFF也当成聚合层；如果站在纯后端视角，聚合层负责复杂的业务逻辑编排，可能是微服务能力编排或应用内子模块能力的编排；
2.原子能力层：相对细粒度的能力，相对稳定。有些业务会把DB的增删改查当成是原子能力，我不建议这样做。原子能力最好是面向业务语义而非数据库语义的；
3.基础层：提供通用的底层支撑能力，和业务场景的相关性不大。
总结
上述这几种分层方法，看似命名和视角不同，但我认为其核心思想没有太大的差异。那为什么会衍生这么多概念和思想，我认为这主要和从业人员造概念、盲目跟风、故弄玄虚有一定的关系。我们在看待这些概念上，一定要看到架构的本质，而不要被概念所迷惑。
分层的本质是为了复用和解耦，上述这几种分层架构的本质，就是基于不同的封装粒度，将能力划分为以下三层：
-
最上层：负责编排业务流程和组装细粒度原子能力，为最前端的多变业务场景提供适配和定制；
-
中间层：沉淀最核心的领域能力，搭建相对稳态的模型和固化的业务规则，属于系统中最内核的部分；
-
底层：负责封装基础的业务能力或通用技术服务，为上层提供支撑；
