前言

企业IT架构包括应用架构、数据架构和技术架构，企业IT架构与业务架构共同构成了企业架构的核心内容。接下来重点介绍IT架构中的应用架构。

应用架构是对企业所有应用系统、服务及它们之间交互关系的整体描述，反映应用系统如何支撑业务运行及未来业务发展，同时需要体现应用与技术、数据之间的关系。其中我们会看看应用架构的本质、价值、设计框架、常用模式、核心策略、设计原则，并重点讨论应用架构的利器——领域驱动设计（DDD），并给出一些参考设计。

企业IT架构概述

企业IT架构承载着业务架构，并指导企业IT和具体项目的开展。业务的开展依赖IT，而IT的需求来自业务。

业务架构向IT架构转化的过程

在企业IT架构设计过程中，我们需要关注IT与业务的关系，理解并转化业务方向，并进行正确的技术选型，提供IT的投资依据，结合数字化转型项目，提高企业业务和技术的核心竞争力。

图例：业务架构向IT架构转化的过程

在业务架构向IT架构转化的过程中，业务架构为IT架构提供了企业业务的输入，通过对战略技术的转化，业务架构把企业的业务通过业务能力、业务流程及更细粒度的业务活动等业务需求具象化地展示出来。进而，IT架构中的应用架构承接这些需求，通过领域驱动设计等设计方法，使用领域服务构建服务化能力，并通过服务化的功能接口等，逐步构建应用系统，同时结合业务发展，构建企业的产品和解决方案。在整个过程中，数据是核心，应用架构中构建的领域模型对数据架构中的数据模型进行输入，指导数据实体等数据分布和分析，并通过技术架构的数据存储进行具体的数据管理。而应用架构产生的应用、产品、服务等内容通过技术架构提供的开发能力实施落地，比如使用微服务、云计算、云原生等应用服务开发方法，并通过技术架构中的基础设施、系统集成等完成整体技术底座的支撑和保障。

企业IT架构总体框架

企业IT架构主要包括应用架构、数据架构、技术架构，具体如下所示。

图例: 基于云原生体系的企业IT架构总体框架

应用架构：涵盖应用、服务、应用组件、功能组件、服务接口等。核心是将业务架构的业务流程和服务翻译成人们可以看得懂的应用服务和服务流程，过程中涉及领域驱动设计、服务化、微服务等相关架构设计能力。此外，应用架构还包括系统、共享中心、产品、解决方案等层面的系统级抽象，这是整个IT架构的关键阶段，决定着企业为客户提供的具体的应用服务功能。

数据架构：描述企业架构的数据模型、数据分布、数据资产之间的结构和关系，是IT架构的核心。数据架构与应用架构的领域模型密切相关，并与技术架构的数据存储紧密相连。数据架构通过数据标准、数据治理、管控流程和技术工具等方面进行制定，并协同业务架构、应用架构、技术架构层面的数据形成统一、完整的数据标准。

云原生技术架构：通过构建企业开发平台、运维平台来协助系统统一管理，并结合敏捷交付、精益管理等管理开发和运维一体化的平台，协助应用和数据等数字化项目落地。云原生体系主要涉及云原生基础设施、云原生应用平台、低代码开发平台、云原生技术组件，以及一些集成平台和安全平台的构建。

应用架构概述

应用架构是对企业所有应用系统、服务及它们之间交互关系的整体描述，反映应用系统如何支撑业务运行及未来业务发展，同时需要体现应用与技术、数据之间的关系。

应用架构是业务架构、技术架构、数据架构，以及企业业务、文化、组织等的成果体现方式，核心是通过建模将业务流程和服务转化成应用系统层面的应用与服务等概念，决定了企业为客户提供的具体的应用服务功能。

应用架构的本质

应用架构的本质其实是建模的过程。

从现实世界到软件应用世界，是一个不断抽象、不断建模的过程，即从业务架构中抽象出业务能力和业务流程，进而对系统和应用建立模型，通过不同层面的模型设计，层层抽象，最终得到用户可以使用的系统，这个过程的本质就是建模。

什么是模型（Model）？

模型指用一个较为简单的东西来代表另一个东西。

比如，科学模型中的数学公式极其简单并准确地表达了某种理论的计算原理。

在架构设计中，模型本身是业务需求的映射，以需求场景为输入，需要根据业务场景来进行验证和完善；同时模型是连接业务和应用系统的桥梁，基于业务的理解，逐步展开，并产出应用中需要完成的服务、功能、接口等。另外，从落地层面，代码是模型的印证，最终模型在项目中通过具体的程序代码，把复杂的业务诉求构建成简单的模型，最终形成应用系统供用户使用。

什么是建模（Modeling）？

百度百科是这样定义的：建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

《大象：Thinking in UML》中是这样定义的：建模是指通过对客观事物建立一种抽象的方法，用以表征事物并获得对事物本身的理解，同时把这种理解概念化，并将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理便于理解的表达。

建模的整个过程可大致分为业务建模和应用建模。

业务建模的本质就是我们前文所讲的业务架构，通过把业务的各种信息作为输入，建立企业业务的顶层视图，核心是识别企业的业务能力和业务流程，以及各个业务活动的组成部分，思考从用户使用的业务场景视角，企业该提供什么样的业务，大致的业务分类和业务逻辑是怎样的，应如何提供这些能力等，逐步通过业务能力和业务流程将业务抽象为“一张图”。

应用建模是在业务建模的基础上，完成业务需求到应用系统模型之间的映射，最终设计出可以供用户使用并能具体解决用户问题的系统。应用建模更强调职责、依赖、约束关系，用于指导研发的落地实现，所以这个过程的核心是如何抽取核心概念，合理地划分这些模型层次，模型之间的边界是怎样的，如何控制模型之间的粒度等。应用建模可以使用不同的方法，如面向对象方法、面向数据方法、面向领域设计方法等，目前领域驱动设计是最受欢迎的设计方法之一。

我们再从业务架构和应用架构之间的关系来看这个建模过程，在从业务架构中识别出业务能力和业务流程后，将基本组成部分抽象成业务活动，而这些业务活动通过应用架构中的模型和服务进行映射，在此过程中，应用架构通过领域模型和领域服务，对业务能力和业务流程进行了翻译和关联，最终设计出相关的功能，并逐步抽象成产品和解决方案。

应用架构的价值

应用架构的价值主要体现在以下几点。

应用架构作为企业IT架构的核心，连接业务架构中业务能力、业务流程和业务需求，也能够连接数据架构的数据管理和使用，同时提出对技术架构和IT基础设施的要求。

应用架构向业务部门提供整体IT应用系统的服务和功能，确保将来的应用与业务需求一致，并保持整体架构的连贯性，对企业系统孤立、功能重复建设、灵活度差、难以共享等问题进行整合和优化。

应用架构对应用系统和服务的整体功能进行统一规划，建立企业应用系统的总体视图。同时，万物皆服务，以服务为中心的应用架构可以解决企业在开发、部署、运维、集成等过程中面临的问题。

应用架构区分企业共享部分与定制化部分，经过应用架构的分层设计，将通用、成熟的功能进行共享下沉，将个性化、特殊的功能开放到更前端的业务部门，便于功能的灵活扩展和业务的快速应变。

应用架构为企业产品化提供支持。经过应用的能力设计和服务识别，为企业进一步优化产品和相应的解决方案提供基于架构视角的主要参考。

应用架构协助团队沟通。通过维护统一、便于理解的应用视图，各业务和技术团队可以保持同频和一致，防止各部门进行重复建设。

应用架构的设计原则

应用架构有比较多的参考设计原则，包括应用设计原则、服务设计原则、服务分层原则、微服务设计原则、接口设计原则、开发设计原则等。在实践过程中，我们可以选择性地加以参考。

应用设计原则

应用设计的总体原则可以借鉴第1章中介绍的架构设计原则，即正交性、高内聚、低耦合、简单适用等。此外，在应用设计过程中，还有如下参考。

边界清晰：每个应用的范围和边界要清晰，没有重叠，无重复定义的应用功能，同时应对应合理的组织。

拆分和分层：在满足业务需求的情况下，多考虑应用和系统如何拆分和分层，控制粒度，将核心、稳定、可复用的业务能力进行抽象和沉淀。

线性扩展：企业需要采用去中心化架构，服务尽量无状态，便于水平扩展。在设计时，还需要考虑应用和服务的扩展能力，如流程扩展、服务扩展、编排扩展、界面配置，以及开放能力和对外集成能力等。

数据化运营：应用功能内部数据共享最大化，应用功能之间共享最小化。通过运营指标驱动，增强数字化运维、监控告警、限流降级、性能分析和诊断等方面的能力。

异步化：互联网应用一般不苛求强一致性，而使用最终一致来平衡。在业务允许范围内，尽可能采用异步解耦，比如不同域之间异步调用，核心业务异步调用非核心业务，而同步调用的，需设置超时时间及重试机制等。

自动化管控：提升自动化运维能力，如自动部署、自动弹性扩容、自动升降级、自动限流降级等，降低运营成本，提高系统的稳定性和业务连续性。

服务设计原则

应用架构是以服务为中心的，在进行服务设计时需要遵循以下原则。

稳定性原则：一切以系统稳定为核心，不允许过度设计，应用架构应尽可能清晰、简单。

松耦合原则：各个应用确保稳定部分与易变部分，核心业务与非核心业务、服务提供者与服务消费者、核心服务与非核心服务、应用与数据、服务与实现细节等分离。

抽象化原则：确保应用抽象化、数据存储抽象化、服务计算抽象化。

容错原则：通过自治、冗余、延缓等手段提高服务的容错能力，通过服务自治、服务隔离、限流降级等避免出现连锁反应，通过集群容错、避免单点、服务中心容灾等提高系统容错能力。

安全性原则：采用多层安全防火设计，提高系统的故障恢复、应急响应能力，阻止来自外部的非法访问，预防黑客攻击，服务数据等安全合规，系统应具备数据备份和恢复能力等。

规范统一原则：通过统一接口方式和管控手段，统一规划建设、统一标准管理，信息共享，协同合作。

开放扩展原则：服务的数据交换符合行业标准，提供服务的扩展能力，包括服务流程、服务接口、应用等多层次定制化扩展能力。

服务无状态原则：服务设计为可以伸缩的，并且可以部署到高可用性基础结构中，尽可能减少服务的状态，或者通过分布式存储方式来保存。

服务分层原则

服务分层对于服务设计非常重要。对服务进行分层后可以使我们讨论问题聚焦在某一层上，降低问题的复杂度。一些服务分层原则如下。

高内聚、低耦合：服务分层的首要原则是高内聚、低耦合，即服务内部高度内聚，服务外部降低耦合度。在分层时，我们可以每次从不同的角度进行，通过多次优化，减少服务与服务之间的依赖。

基于通用性进行分层：稳定、通用的服务向下沉淀，个性、定制化的服务向上沉淀，同时可以设计一些变化的分层来隔离变化。另外，还有其他考虑维度，如是否是非功能性服务、是否是平台类型服务、是否是重要服务等。

团队规模参考：以垂直业务划分开发维护团队，澄清跨团队服务消费需求，并订立服务契约，3～8人的开发维护团队为理想规模。同时，需要架构委员会处理跨域冲突，处理有冲突的服务能力归属等跨组织的协调问题。

数据访问原则：数据归属应该单一化，跨域数据读写需要尽量减少，并且严格遵循依赖原则及接口访问原则。

服务依赖原则：服务分层访问，上层可调用同层或下层服务，禁止下层调用上层服务，同时要对跨层访问次数加以限制，为后续限流降级打好基础。

共享服务划分原则：是否足够通用、普适，是否高度抽象，可以被不同业务进行定制和扩展；是否有业务价值，可以解决某种通用的业务问题；是否有业务数据的持续输入，架构运营的核心是数据，如果一个服务数据输入不足，则可以先不考虑共享；是否能力相对稳定，共享服务会迭代变化，但不应该变化过于频繁。

微服务设计原则

这里从应用服务设计角度介绍一些微服务设计原则。

业务优先原则：当有冲突时，以业务需求为核心。

顶层架构设计原则：以业务架构为设计基础，遵循顶层业务架构的设计。

稳定性原则：以稳定为中心，设计得尽可能简单和清晰，不过度设计。

依赖和分离原则：需要把稳定的服务部分与易变的服务部分进行分离，把核心业务微服务与非核心业务微服务分离，应用与数据分离，服务接口与实现细节分离。

异步松耦合原则：不同业务域间尽量异步解耦；核心业务与非核心业务间尽量异步解耦。

垂直划分优先原则：尽可能根据业务领域进行服务的垂直划分，这样更加关注业务实现，端到端负责，便于持续改进，减少调用次数。水平划分需要充分从总体考虑。

持续演进原则：应逐步划分、持续演进，避免服务数量的“爆炸性”增长。当服务数量增加时，需要考虑持续交付、微服务监控与治理等环节。

服务自治原则：服务需要提供SLA，保持稳定性，可以独立开发、测试、部署和运行，避免发生连锁反应。

自动化驱动原则：可以结合DevOps和CI/CD等自动化工具，以及成熟的微服务治理框架，提高微服务生命周期的自动化效率。

微服务拆分原则：优先拆分比较独立的服务、通用服务、边界明显的服务、核心服务。

接口设计原则

服务之间交流的契约是API，一个好的接口应该是无状态、标准且兼容的，技术上目前采用比较多的是RESTful API。下面介绍一些通用的接口设计原则。

合适粒度原则：平衡可维护性与易用性。可提供普适的粗粒度业务逻辑片段，根据需求增加精细化的服务接口。

强描述性原则：服务名和方法的意义明确，表意精准，服务模式明确，比如是同步还是异步。

内聚完整原则：从服务消费者的角度，考察提供服务的完整性、功能的自洽性。

语义接口原则：接口信息使用语义化封装，内外隔离，接口信息对象独立于服务内部的实现信息对象定义。

接口普适原则：接口信息基本属性尽量使用跨语言的基本类型（字符串、日期、数值等）。

扩展兼容原则：在保证易用性的前提下，尽可能考虑扩展性，避免未来频繁更改接口，同时做好版本管理。

服务命名原则：自描述，易于理解，并且有意义。

契约先行原则：当与其他团队交流时，双方的交流基础就是接口，要形成契约意识，对双方形成强有力的约束，并为双方提供保障。

开发设计原则

在开发过程中，一些关于设计阶段的通用参考如下所示。

定义相关的技术规范：包括服务设计规范、接口设计规范、Java开发规范、产品使用规范、数据库使用规范、部署升级规范、运维规范、编程规范、日志规范、工程规范、安全规范等。

应用开发原则：边界清晰、应用内数据共享；应用间依赖最小化，不存在循环依赖；应用可管理、可监控、可开发、可扩展。

服务开发规范：考虑如下设计，如超时重试、快速失败、结果可预期、服务无状态、幂等性、乱序可容忍、无循环依赖。

应用架构设计框架

应用架构构建业务架构、数据架构、技术架构之间的关联关系。应用架构以企业业务架构为基础，规划整个企业所有应用系统的蓝图，将业务架构中业务流程、业务能力等落实到应用系统的具体功能和服务，并对数据架构的数据分析和管理提供诉求，对技术架构中涉及的开发平台、技术选型、基础设施、集成、安全等提出要求，指导后续架构的部署与构建。

图例：应用架构的设计框架

应用架构的设计框架主要包括以下部分。

应用核心设计：对应用架构的核心内容进行设计，包括应用、领域服务、功能接口及对应的产品与解决方案等。

应用系统设计：应用对应的系统能力设计，确定系统的边界、定义、接口，包括系统对应的表现层、应用层、领域层、基础设施层。

应用架构管理：应用涉及的相关协同管理，包括应用共享、应用开发、应用集成等，也涉及一些技术组件。

应用架构原则规范：包括服务设计原则、服务分层原则、系统集成原则等，以及相关的开发规范、设计规范、设计工具等。

应用架构行业参考：包括通用的一些行业参考模型，提供企业参考、资产沉淀和复用。从以上可以看出，应用架构设计的核心是应用核心设计，而实际过程中领域驱动设计是非常重要的理论参考。

应用架构常用模式

应用架构常用模式主要有以下几种。

集中式架构

集中式架构又称单体架构，传统企业根据各个业务部门的需求，开发了多个“烟囱式”系统，这种架构模式有很多弊端，在一些传统企业中还存在。

SOA（面向服务架构）

企业采用企业服务总线（ESB）来解决多系统之间复杂的接口交互模式，也就是传统的SOA模式。而随着互联网企业的发展，采用去中心化、去IOE的分布式服务架构，不需要ESB作为中心节点，而是进行直接发现和调用，以解决中心化服务扩展难、不适合互联网大流量要求快速响应的痛点。

The Open Group的面向服务架构 (SOA) 工作组提出了一个SOA架构的参考模型，主要包括：

图例：SOA参考应用架构

SOA参考应用架构，具体包括以下几个层面。

基础设施服务：由操作系统和后台的应用系统组成，能够被系统组件调用，实现IT系统服务功能，并确保服务的质量，为各层次的系统提供数据支持。

服务总线：：通常由ESB系统提供路由、多协议、转换等,服务在这里注册和发现，也可以通过组合形成组合服务,并且通过对服务的服务组合和编排实现业务流程。

关键服务组件：由服务使用者组成，构建前台的访问应用。

开发工具：提供SOA的相关开工具，如WSDL等

管理工具：提供服务质量（QoS）服务，包括安全、管理和基础设施监控等。

SOA并不是推倒重建企业的系统，而是在现有的系统之上进行包装服务，建立标准结构，方便互通和调用。SOA也使得架构设计的过程从面向对象、面向组件的设计方法过渡到面向服务的设计方法，其强调以服务为中心的设计理念，接口和实现分离、服务提供和服务使用分层的设计思想。

事件驱动架构

事件驱动架构（Event Driven Architecture，EDA）以SOA为基础，以事件为单位进行各种处理。事件驱动的核心是事件，事件是历史，是事实，是已经发生的事。

图例：事件驱动架构示意

事件由事件源生成，并通过事件管理器进行发布，各种事件的订阅方根据需要进行订阅消费，可以直接处理该事件，或者即时转给其他订阅方，同时事件作为一种业务数据的载体，可以进行存储，从而在以后进行处理。

图例：事件驱动概念示意

事件驱动系统通常是异步的，事件生产者向事件管理器发布事件，如果事件消费者不可用，事件管理器将保留这个事件，之后再次转给事件消费者。

事件生产者与事件消费者相对独立且解耦，事件生产者不需要知道哪个消费者会接收消息。事件消费者彼此之间也互相解耦，每个消费者都可以接收全部或者部分消息。因此，事件驱动架构的系统更适用于包含较多未知因素的环境或者异步的环境，通过构建分布式高可用架构，提供事件生产者和事件消费者相对灵活解耦的能力。事件驱动架构适用于多种场景，比如有多个子应用且处理相同事件，需要实时处理大量数据，有复杂的事件处理等。

图例: EDA领域事件

从领域设计角度，事件驱动架构也有广泛应用，比如基于事件风暴的分析方法。其中，事件源和订阅者都是具体的领域实体，事件管理器可以作为基础设施的一部分技术组件，这个过程会借助消息中间件来进行能力提供。

微服务架构

随着互联网技术的发展，SOA技术进一步进化为以微服务为主流的分布式服务架构。微服务是一种分布式架构模式，微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势，逐渐成为分布式架构的主流。微服务将大型复杂软件应用拆分成多个微小的服务，服务之间是松耦合的，每个服务描述一个小业务，可以独立地进行升级、部署、扩展和重新启动等流程，并通过接口契约、标准协议等保持彼此互通。

微服务架构由SOA演化而来，是SOA的一种特殊实现方式，突出将服务划分为更细粒度的微服务，按照业务领域划分，强调服务编排、服务治理、自动化运维，并具备高可用、性能要求、分布式事务一致等特点。

关于微服务是什么，转述Martin Flower 大神的系统阐述：

微服务是一种架构风格，也是一种服务

微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，比如Netflix目前由500多个的微服务组成

微服务采用UNIX设计的哲学，每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。

图例：微服务架构示例

与集中式架构相比，微服务有降低系统复杂度、提高迭代效率、促进团队沟通、弹性扩展、容错能力、独立部署、可扩展性、跨语言编程等很多优点，这里挑选几个进行说明。

提高迭代效率：支持细粒度的独立迭代和发布，速度快。由于微服务架构中的每个小型服务是独立部署的，可以单个服务进行缺陷修复或者特性变更，无须重新部署整个应用程序，一旦发现缺陷，就立刻回滚服务。

促进团队沟通：单个小型服务仅需要一个小的开发团队就可以完成开发、测试和部署工作。相比之下，更大的团队通常意味着更低的沟通效率、更高的管理开销。

容错能力：当系统出现问题时，将仅影响单个小型服务，不一定导致整个应用程序中断；同时对应的数据也将会进行隔离，风险明显降低。

可扩展性：每个小型服务都支持独立水平扩展，无须扩展整个应用程序，资源的利用率高，扩展快速。每个小型服务都可以独立进行服务升级，并且结合持续集成工具可以进行持续发布，快速完成服务升级和发布流程。

微服务架构有很多好处，不过也存在以下一些挑战。

设计的复杂性：与传统架构的应用程序相比，微服务架构的组件更多。服务数量多意味着部署和管理的工作量更大，还需要考虑分布式系统的复杂性和分布式事务的处理难度。

开发、测试、部署难度：当服务拆分后，几乎所有功能都会涉及多个服务，所依赖的其他独立服务增多，此时处理好服务间的依赖关系成为关键。原本单个程序的测试会变为服务间调用的测试。测试变得更加复杂。

运维难度：由于可能采用不同的语言和框架，应用程序可能变得难以维护。整个应用分散成多个小型服务，这导致问题定位更加困难，同时可能增加服务间的通信量。

数据一致性：每个小型服务都仅负责各自相关的数据持久性，因此不同服务间的数据一致性很难达到。

云原生架构

分布式架构的出现是为了解决应用难以开发和维护的问题。

垂直拆分：把按业务领域拆分为多个松耦合的独立应用，各自独立部署和维护。

水平拆分：把通用的、共性的应用进行分层沉淀，形成共享的服务能力，这样可以对性能稳定性等问题进行统一处理和优化，防止重复开发。

如今，架构朝着越来越轻量化、能力越来越下沉、应用越来越灵活的方向发展，到云原生时代达到了新的高度。

云原生将云应用中的非业务代码进行最大化的剥离，关注点分离，让云来负责原有的大量非功能特性需求，如可靠性、扩展性、可观测性、弹性、轻量、敏捷、自动化等。

同时，有很多企业也在尝试“双IT架构”，即以云原生架构来应对敏态业务的快速变化，以及传统的基于ESB方式的架构应对稳态内部系统的管理，二者相互结合并互补。

应用架构核心策略

应用架构的核心是将应用的领域和服务进行分层划分，其中主要应解决的问题是如何制定边界，划分的粒度怎样定义，怎样对应用架构进行分层。这里我们先讨论一些核心策略。

应用架构边界策略

针对应用架构的边界问题，有以下策略参考。

高内聚：采取统一的概念和定义，在内部的修改不会影响到其他应用，内部功能在总体上保持一致，有助于隔离和管理。

单一职责：各应用服务的功能单一，有助于控制范围边界，保证职责的一致和完整；各应用服务可自治，如可独立部署、升级、自我恢复等。

制定限界上下文：各部分相关行为控制在一个显示边界的范围内，深刻理解业务场景，挖掘业务知识，识别合理的上下文，才能合理定义服务边界。

避免循环依赖及双向依赖：业务组件之间的依赖是分层和单项的，循环或者双向会导致职责不清晰。

避免采用技术边界来划分应用服务边界：比如通过UI层、逻辑层、存储层等，这是技术角度的划分方法，不适合以业务为核心的应用划分。

避免与微服务、云原生技术体系的技术细节相关联：这样容易把简单业务问题复杂化。此外，避免引入过多的IT概念，如云计算平台、技术组件、编程语言、软件框架等。

避免与数据共享和通信模式相结合：数据共享涉及单一数据和分布式数据，而与通信模式相结合会涉及传输过程状态、网络状态等。

跳出“部门墙”思考：避免受限于组织结构，如系统、需求、分析、开发、运维团队等。

应用架构粒度策略

应用架构的粒度粗细需要适度，不宜过粗或过细，应该在满足业务需要、应用场景、管理幅度、扩展方式等多个因素要求的基础上，保持应用和服务的规模。针对应用架构的粒度问题，有以下策略参考。

确定粒度的依据：比如功能、职责、组织、需要的资源等，以及可独立部署性、灵活性和可扩展性。

粒度确认规则：按照职责划分大小，如果是微服务角度，有时也可以以代码量工程为参考，提高开发效率，降低代码风险。

组织跨越原则：建立一个不需要频繁跨越服务和组织边界就可进行修改的应用服务。

功能单一且完整原则：功能的原子性，有回滚或重试能力；同时是完整的，如果再继续细分，就会失去业务意义。

粒度复杂性可控：可以演化、版本化的接口契约，并尽可能使用异步方式来解耦业务。

应用架构分层参考

结合边界和粒度的思考，应用架构可以从多种角度进行分层，下面给出一些通用的参考。从企业要服务对象的粒度角度，可以有如下分层。

企业级服务：企业对外（如与合作伙伴、供应商或者开放平台）提供的服务能力，通过标准协议进行对接。

应用级服务：将业务通过应用服务的形式对外暴露，将企业核心的业务逻辑封装在应用、产品、解决方案中，对外提供能力。

流程服务：把多个服务聚合成一个服务流程并对外提供，可以通过流程引擎或者更友好的流程编排界面来提供。

数据服务：基于数据相关的服务，比如多系统的服务集成、多数据源的数据聚合，实现数据的共享。

服务：提供有价值的、可重复运行的、规范标准的服务活动组件，尽量无状态、可复用、松耦合、可治理。

微服务：更细粒度的服务形态，通过微服务构建的服务，可独立开发、部署和维护，并通过标准接口进行交互。

从应用中服务用途角度，可以有如下分层。

应用层：应用系统，由应用组件组成。

应用组件服务层：应用级别的组件服务。

共享服务层：应用级别共享服务内容。

基础服务层：核心共用的底层服务内容。

规则服务层：用于流程规则配置的服务。

资源服务层：基础资源，如主数据服务模型。

从用户访问层次角度，可以有如下分层。

表现层：对外展示，包括前台页面和各种用户端触点。

应用层：应用系统，由服务层服务组成。

服务层：服务组件，服务化的基本单元。

基础设施层：包括基础设施资源配置，如数据库连接等。

集成层：与外界集成，如企业服务总线。

领域驱动设计

在应用架构的设计中，领域驱动设计（Domain Driven Design，DDD）占据着非常重要的位置，可以说DDD是应用架构设计的核心。

DDD为我们提供了一种架构设计方法，既面向业务，又面向技术，从业务需求到领域建模，从领域服务到技术转化，强调开发人员与领域专家协同。DDD是埃里克·埃文斯（Eric Evans）在2003年出版的《领域驱动设计：软件核心复杂性应对之道》（Domain Driven Design: Tackling Complexity in the Heart of Software）一书中提出的具有划时代意义的重要概念，不过这种领域建模和设计的思想其实早在20世纪就有很多设计人员重视起来。DDD通过统一语言、领域模型、领域划分和服务划分等一系列手段来降低软件复杂度。

DDD的核心思想是业务与技术相结合的一种过程，既强调业务的理解，又强调应用领域建模方法的使用。DDD本质上是面向对象分析的扩展和延伸，它基于面向对象分析技术进行了分层规划，同时对其中的核心概念和划分做了详细的指引。

DDD的价值

DDD对应用架构设计有非常大的指导作用，具体如下所示。

统一语言：团队成员会在有界的上下文中有意识地形成统一语言，便于沟通，减少分歧，以一种所有干系人都能理解的通用语言为相互交流的工具，在交流的过程中形成领域概念，然后将这些概念设计成领域模型。

业务知识沉淀：DDD不以人为中心，而以业务为中心，通过承接业务架构的业务流程和业务能力，并且通过领域知识进行转化，进而反哺业务架构和应用架构。

边界清晰的应用服务划分：用领域模型划分边界来界定哪些需求是合理的，一些需求应该在什么地方实现，不断拉齐团队成员对需求的认知，让设计更加清晰和规范，分而治之，控制规模。

关注点分离：领域模型与数据模型分离，业务复杂度与技术复杂度分离，保持结构清晰，以应对不可预测性挑战。

团队协同：业务人员和设计人员共同参与，这样有助于创建大家都能理解的通用模型，并用该模型来沟通业务需求、数据实体和过程模型。

模型可扩展：很好地对业务需求进行了到领域服务的转化，同时是微服务及项目落地开发的纽带，领域模型是可扩展且易维护的，也提高了相应的可重用性和可测试性。

当然DDD也不是万能的，在采用DDD之前，我们需要考虑是否真正需要，思考以下几个问题可以帮助我们做出判断。

是否以数据为中心，所有操作都是数据库CRUD？

业务逻辑是否只是少量的业务场景和用例？

应用功能是否稳定？

是否已经对业务领域足够了解？

如果以上问题的答案基本都是“是”，说明系统并没有复杂的业务逻辑，则可以用一般的面向数据的架构或者事务脚本等模式。但如果业务逻辑复杂、变化频繁、团队对该领域还缺乏一定的认知，需要进行领域模型和服务的梳理，那么DDD会帮助我们抽象和解决问题。

DDD的设计理念

DDD大体的分析过程中，其中比较关键的几个切入点是通用语言、领域、限界上下文。

图例：DDD分析过程

通用语言（Ubiquitous Language）

业务人员和技术人员在协作过程中，如何讲同一种语言？在DDD中用通用语言来解决。通用语言是理解业务需求和梳理领域知识的过程，也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。通用语言可以定义公共术语，减少概念混淆，消除歧义和理解偏差，提升需求和知识消化的效率，达到概念和代码的统一，使得虚拟概念和具体实现一致。

通用语言可能由团队所有相关角色参加，如业务代表、产品经理、业务架构师、技术架构师、开发人员。同时，领域专家也非常关键，领域专家需要对业务领域非常了解，或者能够跟领域专业人员学习到足够的领域知识。

通用语言建立的过程并不容易，因为技术人员和领域专家在沟通过程中存在“天然屏障”：

技术人员考虑的是类、方法、算法、继承、封装、代码等

领域专家考虑的是订单流程、库存状态、商品类目等

因此，在建立领域知识的时候，双方必须交换知识，彼此深度参与，才可能得出领域模型。知识的范围涉及领域模型的各个元素，如果一方感到困惑，那么应该立刻换一种方式，直到双方能够理解一致。

领域（Domain）

领域是用于确定范围和边界的，DDD将业务上的问题限定归属在特定的边界内，而这些边界就可以叫作领域。为了降低业务理解和系统实现的复杂度，DDD会将领域进一步划分为更细粒度，也就是子域。子域根据自身的重要程度和功能属性又可以划分为三类子域。

核心域：决定应用和系统核心竞争力，它是决定业务是否成功的主要因素，比如电商系统中关注的会员、商品、订单、交易、库存、营销等。

通用域：没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域，比如统一的认证和权限管理系统。

支撑域：既不包含核心竞争力的功能，又不包含通用功能的子域，但该功能子域又是必需的，也就是支撑域，比如某个特定领域的数据字典。

图例：DDD子域结构示例

领域中的核心是领域模型（Domain Model），领域模型具备自己的属性行为状态，并与现实世界的业务对象相映射，领域模型之间具备明确的职责划分，领域对象元素之间通过聚合和引用来关联相应的业务规则，同时反映通用语言中的领域知识。

领域模型通过提炼领域对象，定义领域对象之间的关系、属性和行为，属于DDD的核心产物。

限界上下文（Bounded Context）

领域帮助我们对系统进行拆分，而限界上下文帮助回答各领域之间的边界及它们如何交互。

DDD中有一个形象的比喻，“细胞之所以会存在，是因为细胞膜定义了什么在细胞内、什么在细胞外，并且确定了什么物质可以通过细胞膜”。

这个“细胞膜”就是对限界上下文很形象的举例。

再举个例子，我们在平时的人际沟通中，为了避免同样的词语产生歧义，我们会把这个词语带入语言上下文中去理解其语义。比如，当谈到“苹果”时，有的人可能想到平时吃的水果，而有的人可能想到苹果手机。 图例：DDD领域与限界上下文

限界上下文是一个显式的边界，领域模型便存在于这个边界之内，通用语言必须限制在这个限界上下文之中。在微服务设计中，一般一个限界上下文理论上就可以设计为一个微服务。限界上下文对应用的边界交互有重要作用，可以帮助我们保持模型的一致性，避免边界之外问题的混淆。这一点很重要，因为在大多数组织中，某些术语在不同的业务领域或团队中有不同的含义。

在限界上下文中，通过上下文映射图（Context Map）确立上下文之间的关系，通过上下游来表达依赖，最后形成限界上下文如何在应用程序中相互配合的全局视图。上下文的交互方法有多种，在实际工作中，目前使用比较广的是防腐层和统一协议。

已发布的语言（Published Language）：两个上下文使用共同的语言，比如SOA服务总线定义了一堆XML模型，或者基于共享的文件或数据库，上下文可以基于此进行直接交互。

开放主机服务（Open Host）：又叫统一协议，为上下文之间的服务定义一套包含标准化数据结构在内的协议，比如基于HTTP风格的RESTful接口协议。

共享内核（Shared Kernel）：两个上下文使用一个共同的代码内核作为通用语言，比如两个工程使用同一个Bean基础模型库。

客户/供应商（Customer/Supplier）：一个上下文使用另一个上下文的服务，有显著的上下游依赖关系，比如基于RPC的服务交互方式。

顺从者（Conformist）：一个上下文使用另一个上下文的服务，但彼此之间的关系并不紧密，比如基于消息传递机制的交互模式。

防腐层（Anti-Corruption Layer，ACL）：使用一层适配层来协助上下文的交互，隔离业务逻辑，比如在商品子域和采购子域之间提供防腐层，将商品的变更进行收口，隔离子域内的后端业务实现。

这里先就领域和限界上下文举一个简单的例子，此处举一个关于购物车订单支付下单的例子。

图例：DDD领域与界限上下文示例

购物车进行在线的支付授权，订单处理下单过程，并触发支付域的付款结算。

这里我们简化整个建模的过程，假设已经抽象出购物车域、支付域、订单域（通常购物车域也可以被包含在订单域内），核心的Cart、Payment、Order。

领域之间通过限界上下文进行交互，因为购物车域和支付域密切相关，需要等待支付授权，我们通过ACL进行关联；而订单下单和付款动作相对解耦，通过领域事件在订单已下单后，触发支付域的付款动作。

DDD的核心概念

DDD在构建领域模型的过程中，涉及比较多的概念。这里着重解读一下以下几个。

图例：DDD的核心概念

实体（Entity）

实体是一个具有唯一身份标识的对象，并且可以在相当长的一段时间内持续变化。

我们可以对实体进行多次修改，一个实体对象可能和它先前的对象大不相同，但拥有相同的身份标识，即依然是同一个实体。

对实体而言，重要的不是其属性，而是其延续性和身份标识。一般实体的唯一标识有两种生成方式。

应用可以自动为实体生成唯一标识，比如JDK自带的UUID、数据库的自增序列

有时也需要综合业务语义来考虑，比如通过业务属性、时间、IP等因素生成

另外，实体具有可变性，这里需要引出两个概念：

贫血模型：贫血模型与Bean或者DO对象类似，一般只有Getter和Setter方法，只作为保存状态或者传递状态，不包含业务逻辑，这种只有数据没有行为的对象不是真正的领域对象

充血模型：DDD中的实体属于充血模型，会封装包含这个实体相关的所有业务逻辑，它既是多个业务属性的载体，又是操作或行为的载体。

以订单（Order）为例，Order有下单、发货和退单等行为，而面向数据设计方式是将这些行为放到另一个服务OrderService中，而不是Order对象中。

值对象（Value Object）

值对象是只关心属性的对象，并且是一个没有标识符的对象。

值对象本质上是一个集合，这个集合中包含若干用于描述目的、具有整体概念和不可修改的属性。它可以避免属性零碎，使属性归类更加清晰，从概念理解上也更加完整。

值对象在领域模型中是可以被共享的，它们应该是不可变的，当有其他地方需要用到值对象时，可以将它的副本作为参数传递。

值对象与实体的区别在于：

值对象一般依附于实体而存在，是实体属性的一部分。

值对象没有唯一标识，当任何属性发生变化时，都意味着新的值对象产生。

值对象功能单一，一般是贫血模型。

以Order为例，订单下的送货地址（Address）就是典型的值对象。Address并不随着Order的产生而产生，它相对不变，也不需要单独标识。

领域服务（Domain Service）

领域中的一些概念不太适合建模为对象，它们本质上是一些操作、一些动作，代表领域中一个重要的行为。这些操作或动作往往涉及多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作，这就是领域服务。

领域服务有一个重要的功能就是可以避免领域逻辑泄露到应用层。如果没有领域服务，那么应用层会直接调用领域对象完成本该领域服务执行的操作。

领域服务体现的行为一定是不属于任何实体和值对象的，但它属于领域模型的范畴，同时领域服务应该是无状态的，应确保领域服务和通用语言是一致的。

领域服务是无状态的

领域对象是有状态的

虽然服务本身也是对象，但它没有属性，只有行为，因此说它是无状态的。

以订单发货（OrderDelivery）为例，需要Order和履约两种实体之间通过一定的业务逻辑，确保事务可以作为领域服务。

聚合（Aggregate）

聚合的核心思想是将关联减至最少，这样有助于简化对象之间的遍历，使用一个抽象来封装模型中的引用。

聚合由两部分组成：

一部分称为根实体，是聚合中的特定实体。根实体是聚合中所包含的一个特定实体，是唯一允许外部对象保持对它的引用的元素。

另一部分描述一个边界，定义聚合内部有什么。边界内部的对象之间可以互相引用。

除根实体外的其他对象都有本地标识，但这些标识只有在聚合内部才需要加以区分，因为外部对象除根实体外看不到其他对象。

聚合行为被视为一个整体，在每个行为完成时，必须满足聚合内部所应用的固定规则的要求，即保证数据变化的一致性。

根实体最终检查固定规则，如删除操作必须一次删除聚合边界之内的所有对象。

过程中有一些最佳实践，比如可以设计一些小的聚合，通过唯一标识引用其他聚合，并且在边界之外考虑最终的一致性。

比如，订单域可能有很多实体，如Order、子订单、订单明细、地址、物流信息、支付信息等，而在我们将它们聚合为订单域后，这些实体都聚焦在一起，并由Order这个实体作为聚合根对外交互。

工厂（Factory）

当创建一个对象或创建整个聚合时，如果创建工作很复杂，或者暴露了过多的内部结构，则可以使用工厂来进行封装。也就是说，将创建复杂对象的实例和聚合的职责转移到一个单独的对象，这个对象本身在领域模型中可能没有职责，但它也是领域设计中的一部分。

设计模式中的工厂类和工厂方法与领域模型中的工厂概念是相似的，其可以帮助我们封装复杂的对象创建过程。

我们可以把工厂作为一种创建复杂对象和聚合的实现方式。工厂用来封装对象创建所必需的知识，它们对创建聚合很有帮助。当聚合的根建立时，所有聚合包含的对象将随之建立。

资源库（Repository）

在DDD中，资源库作为对象的提供方，能够实现对象的持久化，解耦领域内业务逻辑与底层持久化。

每个聚合类型可以对应一个资源库，过程中需要避免实体和值对象成为单纯的充血模型，我们需要资源库把ORM框架与领域模型隔离，以屏蔽数据访问的技术复杂度。资源库可以获取持久化对象，使应用程序和领域设计与持久化技术解耦，让我们始终聚焦于模型，并且将所有对象的存储和访问操作交给资源库来完成。在面向接口和依赖注入机制支持下，资源库也容易通过Mock等方式进行测试。

图例：DDD中资源库模式

工厂和资源库之间存在一定的关系，它们都能帮助我们管理领域对象的生命周期。然而，工厂关注的是对象的创建，而资源库关心的是已经存在的对象。

当一个新对象被添加到资源库时，它应该是先由工厂创建过的，再被传递到资源库，以便更好地保存它。

另外，资源库和数据访问对象（Data Access Object，DAO）的作用类似，但也有所不同，资源库以“领域”为中心，所描述的是“领域语言”，不涉及数据库实现的细节；而DAO是比资源库更低的一层，其包含如何从数据库中提取数据的代码。

领域事件（Domain Event）

领域事件表示领域中所发生的重要事件，在事件发生后通常会导致进一步的业务操作，或者在系统其他地方引起反应。

领域事件非常重要，我们在系统设计过程中经常需要解耦，技术人员一般通过MQ方式进行；架构人员可能采用事件驱动架构（Event Driven Architecture，EDA）的方式。Serverless架构中核心的就是基于事件编程，这一切的核心就是对领域事件的设计，不过当前大部分系统事件（Event）设计比较随性，从而导致Event滥用和无用情况发生，而领域事件是对我们很好的指引。

比如，在订单的例子中，在订单下单后，会进行库存冻结、支付状态更新、物流同步等，这些都是对系统事件良好的解耦设计。

Event命名：Domain Name + 动词的过去式 + Event，如OrderCreatedEvent。

Event内容：Enrichment（Payload中放Data），Query-Back（通过回调拿到更多的Data）。

Event管理：通过MQ等保存所有的Events，并提供良好的Event查询和回溯。

Event处理：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等。

小结

图例：DDD核心概念总结

图例：DDD核心概念职责与关系

DDD常用的分析方法

DDD常用的分析方法主要有用例分析法、四色建模法和事件风暴法。

用例分析法

用例分析是比较通用的领域建模方法，可以在比较传统的需求调研过程中结合领域模型的设计思路进行，核心是通过业务需求、场景流程等梳理用例，进而规划领域模型。

用例分析的前提是业务架构的需求输入，其中核心是业务能力与业务流程。

比如电商领域的订单寻源、库存锁定、商品价格计算、优惠券核销等业务能力，以及订单处理、分单和拆单、逆向退款等业务流程。

每个用例应该面向一个或多个场景，场景主要说明应用是如何和最终用户互动的，也就是谁可以使用应用做什么，从而获得一个明确的业务目标。

编写用例时要避免使用技术术语，应该使用最终用户或者领域专家可以理解的语言，进而我们可以基于用例分析法，根据语义来整理用例，然后整理领域模型，大概步骤如下。

图例：用例分析法过程

收集用例：从业务能力、业务流程、业务需求描述中进行提取，收集相应的名词、动词、形容词，以及对应的业务场景。

提取实体：从名词中定位出主要实体，如商品、SKU、品类等。

提取属性：从形容词中添加实体属性，如颜色、价格等。

添加关联：从动词或形容词中添加实体和实体之间的关联，如商品“包含”SKU，卖家“开设”“多家”店铺等。

完善模型：识别出初步模型，验证并迭代模型，同时补充用例验证模型、业务流程验证模型。

举个关于电商的例子:

假设有这样的需求描述：“会员使用代金券兑换了很多促销的商品。”

我们先从名词“会员”“代金券”“商品”中提取实体，并从形容词“促销的”提取商品的属性，进而将动词“使用”“兑换”识别成关联，同时结合行业知识得知，代金券属于优惠券的一种，最终得出领域模型。

图例：用例分析模型示例

四色建模法

四色建模法在实践中也比较常用，其包括以下几个核心概念。

时间记录（Moment-Interval）：具有可追溯性的记录运营或管理数据的时刻或时段对象（如用粉红色表示）。

人货场（Party-Place-Thing Archetype，PPT）：代表参与到流程中的参与方、地点、物（如用绿色表示）。

角色（Role）：在时间记录与PPT对象（通常是参与方）之间参与的角色（如用黄色表示）。

描述（Description）：对PPT对象的一种补充描述（如用蓝色表示）。

简单地说，四色建模法关注的是，某个人（Party）的角色（PartyRole）在某个地点（Place）的角色（PlaceRole）用某个东西（Thing）的角色（ThingRole）做了某件事情（Moment-Interval）。

下面以一个课程报名缴费的例子对四色建模法进行说明。

报名人可以为学生进行报名，产生对应的报名登记记录和课程表，进而缴费人进行缴费，产生缴费记录。

在这个过程中，“人”有学生和课程，对应的“角色”是报名人和缴费人，完成的“时间记录”是报名登记记录、课程表及缴费记录，再加上一些补充描述。

图例：四色建模法示例

事件风暴法

事件风暴又称事件建模，与头脑风暴类似，可以快速分析复杂的业务领域，完成领域建模的目标。

事件风暴是事件驱动设计的典型代表，是一种快速、轻量且未得到充分认可的群体建模技术，它对于加速开发团队非常适用。

事件风暴法关注以下元素。

事件：发生了什么事情，产生了什么结果（如用橘黄色表示）。

属性：事件的输入、输出，是对时间的细化描述。

命令：某个动作的发起者，可能是人、外部事件、定时器等（如用蓝色表示）。

领域：领域的聚合、内聚、低耦合，聚合内部保证数据的一致性（如用黄色表示）。

简单理解就是谁在何时基于什么（输入）做了什么（命令），产生了什么（输出），影响了什么（事件），最后聚合成了什么（领域）。

事件风暴催化并加速整个建模过程，强调正确的人（业务人员、领域专家、技术人员、架构师、测试人员等关键角色都要参与其中）、开放空间（有足够的空间可以将事件流可视化，让人们可以交互讨论）、即时贴（至少三种颜色），关联的人充分讨论，集体决策，从价值角度来审视业务流程的合理性。领域事件容易促使业务人员和非业务人员达成共识。

下面通过一个电商的例子说明事件风暴的主要过程。

首先，我们基于业务流程和业务流程的输入，对事件进行头脑风暴，主要识别应用层面的主要状态结果。比如识别出“商品已创建”，“库存已扣减”，“订单已支付”等。

其次，我们来识别命令，即什么人做什么事，可以识别出运营人员可以添加商品和编辑库存，用户可以创建订单，并伴随着对应的事件

再次，我们来进行聚合，即将相关的实体聚合在一起，可以看到商品、库存、订单三个领域初步识别，并与相关的命令和事件结合在一起

最后，我们对这些领域进行边界划分，识别出对应的限界上下文。

图例：事件风暴示例

DDD分层架构

DDD在具体落地实施的过程中，强调四层分层结构，将核心概念进行有效的整合，各层的职能定义如下。

图例：DDD分层架构

展示层（Facade Layer）：负责与不同用户和应用之间的交互协议和数据格式的转换，因此它又叫用户接口层。

应用层（Application Layer）：应用层是很薄的一层，负责展示层与领域层之间的协调，它是与其他系统的应用层进行交互的必要渠道，负责对领域层组件进行简单封装，例如事务、调用应用程序的任务。应用层要尽量简单，其服务及方法一般以用例为对应关系，通常一个用例对应到一个应用层的服务方法，方法中不包含业务规则或者知识，不保留业务对象的状态，只保留应用任务的进度状态，更注重业务能力或者业务流程的相关展示。主要通过调用领域层和基础设施层来完成协调。

领域层（Domain Layer）：领域层是DDD的核心，包含一些核心概念，如领域实体、值对象、领域服务、聚合，以及它们之间的关系。它主要负责表达业务概念、业务状态信息及业务规则，具体表现形式是领域模型。DDD提倡充血模型，即尽量将业务逻辑归属到领域对象上。

基础设施层（Infrastructure Layer）：基础设施层向其他层提供通用的技术能力，为应用层传递消息（如API网关等），为领域层提供持久化机制（如数据库资源、中间件交互等），屏蔽技术底座能力（如底层服务的健康度检查、配置参数等）及其他通用的工具类服务。

除了比较经典的四层分层架构，DDD还有一种松散分层架构，即端口适配器架构。

图例：端口适配器架构

端口适配器架构通过划分内部和外部，系统由内而外围绕领域模型展开。领域部分位于最内层，应用程序包含领域模型和业务逻辑，对于外部而言，通过各种适配器进行上下文集成，包括数据持久化、第三方数据集成，同时基于依赖注入和Mock机制，适配器完成便捷的替换和模拟。

不论哪种分层架构，都遵循以下几个通用的DDD分层原则。

无环依赖原则：组件的依赖关系中没有环路，如果出现，则需要打破循环依赖。

稳定依赖原则：被依赖者应该比依赖者更稳定，同时组件的抽象程度应该与其稳定程度保持一致。一个稳定的组件应该是抽象的，这样便于扩展。

依赖倒置原则：高层次的模块不应该依赖低层次的模块，它们都应该依赖抽象。抽象不应该依赖具体，具体应该依赖抽象。

DDD与周边概念的关系

下面我们来看看DDD与一些周边概念的关系。

DDD与数据驱动设计的关系

DDD给我们带来的是设计模式的改变。DDD的设计模式与传统的面向数据驱动的开发模式有明显的区别。

数据驱动设计从数据出发，先梳理E-R图（实体-联系图），设计数据库表结构，编写DAO，然后实现业务逻辑。数据驱动设计主要采用贫血模型，业务逻辑散落在大量的方法中，当系统越来越复杂时，开发时间将成倍增长，维护成本很高。

DDD从领域出发，分析领域内模型及它们之间的关系，并进行领域建模，设计核心业务逻辑，进而实现技术细节。通过DDD，定义领域模型，从而确定业务和应用的边界，保证业务与代码的一致性。

在DDD中，领域模型和数据模型是解耦的，有时也不是一一对应的，因此在应用DDD进行设计时，一定要摆脱数据模型优先的束缚，不要让领域模型被数据模型“绑架”，设计出合理的领域模型是首要任务。

DDD与微服务的关系

微服务是技术层面的分布式技术架构模式，是技术实现和部署的范畴，它提倡将应用划分成更细粒度的服务，服务之间互相协调、互相配合，为用户提供最终价值。

DDD根据限界上下文设计出的领域模型和领域服务，通过微服务进行落地，并结合微服务及其他分布式技术（如DevOps、CI/CD、秒杀、全链路压测等），加速系统的落地。一个域服务可由一个微服务来实现，也可根据DDD领域分析拆分为多个微服务，对外集合成统一的域服务。

DDD与企业架构的关系

DDD在企业架构中扮演着重要的角色。DDD不仅是应用架构中领域建模重要的设计方法，同时在企业架构中承接业务架构，并对技术架构及具体落地时微服务等技术实现都有着重要的指导作用。更重要的是，DDD建立了共同语言，让企业的业务人员和技术人员可以高效地沟通。同时，有些企业强调共享能力中心的设计和沉淀，DDD可以作为其模型和服务建设方法，结合其他架构服务设计模式及相关的最佳实践，助力企业的架构设计与规划。

DDD与开发实施的关系

DDD带来了很多好处，本质上是设计模式的改变，让领域与数据解耦，从业务需求出发，从领域出发，分析领域内模型及它们之间的关系，并进行领域建模，设计核心业务逻辑，进而实现技术细节。DDD起到了承前启后的关键作用，其不仅将业务人员和技术人员连接起来，还把系统从需求、设计、开发、部署、运维整个生命周期环节有效地串接起来，DDD更多地从总体和顶层设计，从问题域、解决方案域、业务模型角度，不深度干预其他环节细节，边界清晰，关注点分离。

应用架构的设计方法

下面我们来看看应用架构的设计方法。应用架构的设计大概分为以下几个阶段。

图例：应用架构设计方法整体概述

阶段1：需求分析

图例：应用架构设计-需求分析阶段

本阶段的主要工作就是进行需求分析。

通过业务架构中的业务能力与业务流程，进一步梳理业务流程，提取业务活动及相关操作。这个阶段要和业务团队紧密合作，了解真实的业务流程和业务需求，并通过业务语言建立统一的沟通语言，确定相关的流程图、状态图，对可能的业务域及相关的业务能力进行描述，识别关键场景和热点域。同时，要多方面收集信息，收集信息时可以从局部到整体或者从整体到局部，尽量将各域的关键信息都收集到。

阶段2：领域模型设计

图例：应用架构设计-领域模式设计阶段

通过DDD，结合第一阶段的需求分析，整理收集到的关键信息，并通过DDD的用例分析法、四色建模法或者事件风暴法，初步识别领域服务及相关的界限上下文等关键信息，进而得出初步的领域模型。在此过程中，分析应用相关的业务功能和应用组件，构建业务活动与应用的关系，建立映射，进而通过领域建模，识别核心领域功能、领域模型，分析应用架构的风格，并初步梳理应用架构对技术架构和数据架构的风格要求。

阶段3：服务设计

图例：应用架构设计-服务设计阶段

服务设计主要包括服务识别、服务筛选、服务目录、服务分类、服务接口等。

服务识别：基于领域识别的服务，初步基于分层原则进行梳理，如服务之间的依赖关系、独立原则，作为候选服务列表。

服务筛选：对候选服务进行评估和筛选，可以从范围、复用度、敏捷度、能力要求、易用度、边界、风险、性能等多维度考虑。

服务目录：定义服务应用领域，定义服务和应用的边界，定义服务规约，识别服务类别和范围，如功能范围、安全策略、交互模式、质量要求等。

服务分类：根据服务的不同层次对服务进行分类，可以分为企业服务、应用服务、流程服务、数据服务、共享服务、微服务、集成服务等。

服务接口：进行服务的接口描述，为实现做指引。将抽象出来的业务服务进行接口化梳理，需要做到职责单一、进行版本管理等。

阶段4：应用架构初步设计

图例：应用架构设计-应用架构初步设计阶段

此阶段进一步从整体分析应用架构。通过整体的一张图体现系统核心应用的分布，以及它们之间的交互关系，为后续数据架构和技术架构作为重要的输入。

这时候，我们得到了初步的应用架构，接着可以进一步分析现状应用架构和目标应用架构，此时不用关注如何实现这个过渡，重点是明确当前和未来，进而我们可以通过架构委员会，对应用架构进行整体的评估，并且可以邀请相关的业务和技术专家参与。

我们要重点分析应用架构的各个组成要素，现状应用架构和目标应用架构，领域模型和服务设计是否合理，是否可以指引后续架构和项目的进行，使得企业所有人员可以清晰地了解应用架构的定位与发展方向。

阶段5：优化迭代

图例：应用架构设计方法-优化迭代阶段

应用架构需要不断地迭代和优化，因为应用架构涉及系统的方方面面，连接着业务和技术，在这个过程中我们很容易有考虑不周之处，这就需要制订一个迭代的计划，同时需要包含架构治理层面，如用架构的评估和激励机制加以支持。

此外，从服务生命周期的完整性角度来说，除了服务设计，还涉及计划、设计、实现、测试、发布、运行、升级、弃用等生命周期。下面补充一些环节，大部分需要在后续章节的技术架构部分加以考虑。

服务实现：通过DDD、微服务或者云原生方式，进行服务的实现，并考虑服务接口、版本、协议，以及服务开发、测试等流程。

服务注册：注册中心的协调，如注册中心与服务消费者、提供者之间的同步及问题排查等，确保相关的数据一致。

服务组合：通过对服务进行编排，构建组合服务或者流程服务，实现企业的业务流程，或者通过更友好的界面配置等低代码能力简化实现。

服务发布：服务对外发布，包括服务注册极限的管理，通过服务注册中心使得服务提供者和消费者可以进行交互。此过程包括灰度发布、滚动发布等发布形态。

服务部署：将服务部署到运行环境中，可以采用静态或者动态部署方式，并且需要考虑系统的资源，包括扩容、版本管理、升级策略等。

服务监控：监控服务的健康状况，如服务链路情况、基础资源情况等，对服务的安全性、性能和可用性进行服务追踪、性能优化、一致性和兼容性管理。

服务测试：测试服务的功能性和非功能性指标。

服务终结：服务的最后一个状态，不仅需要更新注册中心中服务的状态，还需要考虑终结的节奏，比如灰度分批，并与业务方沟通好。

服务治理：包括服务新增、修改、删除等版本管理，对应的升级替换管理，以及服务质量保障，如提供服务的SLA管理、部署和验收、集成管理等。

服务安全：对服务进行必要的访问控制、鉴权控制及必要的数据保护等。

在应用架构设计过程中，可以采用一些理论和工具，如DDD、ArchiMate、UML（统一建模语言）等。

不过，应用架构的重点是进行应用功能和服务能力的识别，最终的结果可以借助文档、绘图工具，我们可以选择通用的架构设计工具，如EA、Archi等。

应用架构与产品的关系

我们来看看应用架构与周边概念的关系。

与产品的关系

应用架构可以体现企业产品化的规划，有时产品架构可以用应用架构的形式表达，其本质上是以产品的视角进一步抽象领域建模，进而进行高度的产品抽象。产品设计本身是一个很大的主题，是产品经理关注的事情，应用架构关注更多的是产品的组成部分及各组成部分之间的关系。

图例：企业架构中应用架构与产品的关系

上图展示了企业架构中应用架构与产品的关系，可以看出，产品的原型设计、上线试运营、效果监控、产品化迭代与企业架构有紧密的联系，其中应用架构具有重要的作用，包括产品组装、能力扩展、领域服务、领域模型、应用组件等，可以给产品从产品形态、运营模式、迭代开发等方面提供很多反馈，对企业业务运营模式、产品迭代方向有着重要的指导作用。

与解决方案的关系

有的企业在对外提供产品的同时，也对外提供解决方案，它们通过对客户聚焦的行业或特定领域提供解决方案，在服务好客户的同时也对产品进行更好地组合和优化。

解决方案本身是企业架构之外的主题，不过从应用架构层面来说，解决方案属于整体的最上层，解决方案通过对产品、应用的组合，更加适应不同垂直细分客户的诉求。解决方案也可以进一步细分为行业解决方案、通用领域解决方案、产品定制解决方案、生态解决方案等，而行业解决方案还可以细分为新零售、金融、政府、教育、物流、医疗、能源、文化、旅游、房地产等。应用架构中的一些关键要素（如应用和服务）是否可以快速组合，是否可以重用和方便扩展，是否足够稳定等，也决定了解决方案的构建效率。

与服务、微服务的关系

服务原则上有业务服务、应用服务、系统服务等多种分类。在业务架构中，业务服务要通过业务能力和业务流程来体现，在应用架构中是应用服务、系统服务所在的主体。

应用服务是构成业务活动的基本单元，而业务活动是构成业务能力和业务流程的基本单元。同时，应用架构基于DDD，又可以分为应用层和领域层，也就是有对应的应用服务和领域服务，通过层次的分离，可以很好地降低各个服务的复杂度及依赖度。

图例：应用架构与微服务的关系

业务架构把企业的业务通过业务能力、业务流程及更细粒度的业务活动等具象化地展示出来。应用架构承接这些需求，通过DDD，使用领域服务构建服务化能力，并通过服务化的功能接口等，逐步构建应用系统，同时结合业务发展，构建企业的产品和解决方案。微服务是应用架构的一种落地实现方式，其中很多设计原则的指导适合应用架构（如微服务的划分方法），同时涉及一些技术层面，这个在技术架构和项目运营治理中有所关联，如DevOps和CI/CD。同时，微服务架构的设计过程从面向数据的过程转变为面向领域和面向服务的过程。微服务其实贯穿了应用服务设计、技术侧的微服务开发框架、项目管理与运维侧的持续集成和自动部署等。

共享服务中心的关系

有些企业将核心能力以数字化形式沉淀为各种共享服务中心，并强调通用能力的沉淀，而本质上共享服务中心是应用架构的一部分，是其中共享应用或者共享服务的。应用架构的关键概念、DDD建模方法、相关的原则规范对共享服务同样适用。

在电商领域，后台系统（如商品系统、订单系统、库存系统等）以共享服务中心的方式，承担通用的共享能力，整合、屏蔽下层系统，提供前端敏捷访问。

企业级应用架构参考设计

TAM应用架构参考

TM Forum理论提供了一个关于The Application Framework（TAM）的企业应用架构的参考。

TAM是TM Forum中开放数字化架构框架的一部分，为企业应用架构框架提供了一个通用的方法。

TAM涵盖产品、运营、服务、保障等纵向业务，以及市场销售域、产品管理域、客户管理域、服务管理域、资源管理域、供应商/合作伙伴域、企业管理域等多领域需要的应用功能参考，这些多维的应用功能地图为定义和复杂的应用系统提供了一个范例。

TAM这个模型既没有根据DDD给出分析的过程，也没有给出具体的领域模型和服务，但从整体上给出了一个企业在不同域中需要考虑的核心应用功能，有比较高的参考价值。

图例：TAM应用架构参考

企业ABC应用架构参考

新零售应用需要的功能和服务多样，接着业务架构章节提到的鞋服企业ABC案例，我们来看看应用架构如何进一步结合业务架构落地。在业务架构部分，一些业务能力，如商品流转能力、库存平衡能力、订单寻源能力、分润结算能力、会员营销能力等，同时伴随着很细致的业务流程。应用架构为了承载这些业务能力和业务需求，需要进行应用与服务的构建。大体把应用分为四层（其中业务能力承载自业务架构，这里先不包含进来）。

前台应用：面向不同的用户的前端触点应用，这些应用直接面向最终用户，是业务能力和业务流程的入口。比如，面向线下门店店员的POS系统，面向线上营销人员的自营电商、第三方电商，以及多种多媒体营销渠道（如微信、微博、抖音），或者一些直播、微分销平台等。

核心应用：支撑业务的核心能力，形成企业的共享复用能力，支撑业务能力和业务流程的沉淀，通过核心的领域服务进行承载，可能涉及企业的多个方面，如商品系统、渠道系统、库存系统、交易系统、用户系统、会员系统、营销系统、结算系统等。

后台应用：企业内部的稳态的管理系统，更多需要和核心应用及前端进行对接，提供企业内部管理的方方面面，如生产管理、物流管理、仓储管理、财务管理、人力资源管理、行政管理、物料生产管理、其他资源管理等。

基础设施：支持这些系统的基础设施，如计算设施、存储设施、网络、中间件、安全设施、云原生等。

图例：企业ABC应用架构参考

企业ABC的核心领域模型

企业ABC在具体的核心应用系统设计中，进一步可以聚焦相关的主要能力、领域模型及领域服务，建模过程可以参考DDD及相关的应用架构设计方法，进而可以得到领域模型。

整个设计过程的内容比较多，这里只做简要说明，这里仅展示几个核心的领域，比如用户域、会员域、营销域、订单域、商品域、库存域，里面的实体、值对象、领域服务及领域事件等仅展示部分内容。

企业ABC对不同的核心领域进行应用系统建设，为了方便开发和管理，每个领域对应一个应用系统，这里简单总结一下这些应用系统的主要能力、核心模型（包括聚合、实体、值对象等）和核心服务（包括领域服务、领域事件等）。

图例：企业ABC的核心领域模型

商品系统

主要能力：建立和维护统一的商品库，并提供商品的管理和运营能力，为上层业务提供简单、统一的商品与服务。

核心模型：商品、类目、品牌、价格、属性、产品SPU、SKU、商品详情等。

核心服务：基础数据管理，包括品类管理、产品SPU管理、SKU管理、属性管理等；品牌类目管理，包括商品品牌的维护与查询，商品类目的维护与管理；商品发布管理，包括商品上架和下架管理、商品发布与编辑等；价格管理，包括销售价、批发价、零售价，以及价格生效/失效时间；商品组合管理，包括组合SKU、临时组合等；评价管理，包括商品评价、回复管理等；产品管理，包括对产品模板的创建、编辑、查询、禁用等。

渠道系统

主要能力：建立和维护统一的上游和下游组织网络渠道，并提供地区、门店、店铺、供应商、经销商等管理和运营能力，为上层业务提供简单、统一的渠道与服务。

核心模型：门店、店铺、供应商、经销商、类目、地区等。

核心服务：渠道数据管理，包括对渠道的创建、编辑、查询、停用等；渠道关系管理，包括渠道与仓库的关系、渠道与组织的关系、供应商与组织的关系等；店铺管理，包括商户管理、店铺会员管理、店铺装修、店铺开通等；其他服务，如门店管理、供应商管理、经销商管理等。

库存系统

主要能力：对仓库统一管理，管理所有的物理仓、门店仓、电商仓，提供统一库存管理模型和算法，支持多渠道库存实时共享，基于虚拟库存模型实现库存共享和自动调配。

核心模型：实体库存、逻辑库存、共享库存、渠道库存、出入库单据、出入库单据明细、出入库通知等。

核心服务：库存管理，包括库存寻源、库存占用、库存共享、自动调配等；库存状态管理，包括可用、在途、占用、共享等；仓库管理，包括逻辑仓、实体仓、渠道仓的管理；货品管理，包括货品出入库、调拨、盘点等；库存同步，包括渠道仓库、逻辑仓库、实体仓库之间的同步。

交易系统

主要能力：交易系统也可以叫订单系统，新零售应用主要围绕订单来进行，负责企业业务交易订单的整个生命周期管理，包括订单生成、合并拆分、流转、发货、退换货等，涉及企业多种业务模式，如线下门店自提、线上销售、O2O等，特别是通过订单的不同交易节点进行流程编排和配置化等。

核心模型：主订单、子订单、订单状态、订单明细、订单日志、退货单、换货单、物流单。

核心服务：购物车管理，包括购物车商品添加、编辑、查询等；正向交易管理，包括交易订单生成、订单转换、发货通知等；逆向交易管理，包括商品换货、退货、退款等；订单数据管理，包括交易订单记录等；订单管理，包括订单拆分合并、订单寻源等；订单状态管理，包括已加购、待付款、待发货、已收货、售后中、退货中、退款中等。

用户系统

主要能力：存储和维护统一的用户和组织库，并提供人员信息、组织机构、用户信息的管理和运营能力，为上层业务提供统一的用户与服务。

核心模型：用户、员工、组织、角色、权限、账号等。

核心服务：组织管理，包括对组织级别、组织属性及属性组管理；人员管理，包括人员添加、查询、角色权限配置等；账号管理，包括系统账号、密码管理等。

会员系统

主要能力：统一会员生命周期管理，促进用户购物、提高用户黏性，提高AIPL转化，关注拉新转化、复购、客单价等。支持多个品牌会员体系，以及会员权益发放与兑换，会员积分、等级权益的服务，通过会员系统收集和分析会员的消费行为和画像；支持多种业务场景，如社交营销、消费即会员、无感积分等。

核心模型：会员、等级、权益、积分、成长值、画像、付费会员、会员标签等。

核心服务：会员运营管理，包括会员注册、个人信息维护、会员卡办理等；会员体系管理，包括会员体系的创建、积分规则、成长值规则、等级、权益等；会员积分管理，包括积分获取、核销、清零、兑换等；基础信息服务，包括成长等级、审核认证、行为触点服务、积分活动等。

营销系统

主要能力：提供营销体系，如活动支持满减、满赠、满折、特价、抽奖、红包等，支持营销活动规则的制定和发布，支持多渠道优惠券、折扣券的管理、发券及核销。

核心模型：活动模板、营销活动、活动规则、营销工具、优惠券等。

核心服务：活动模板管理，包括营销活动的策略类型、策略模板、规则配置、动作模板等；活动管理，包括基本信息、店铺圈选、商品管理、活动频次、触发条件，活动发布等；优惠券管理，包括优惠券的发放、领取、查询、使用、核销等。

结算系统

主要能力：提供企业核心财务结算管理，提供业务规则、结算规则、业务结算、财务对账等服务能力。

核心模型：资金账户、支付渠道、结算类型、结算主体、结算单、支付网关等。

核心服务：结算主体管理，包括经销商主体、企业多主体管理等；结算规则管理，包括结算来源、转换规则、支付方式等；资金账户管理，包括经销商资金账户、信贷维护和审批等；财务结算管理，包括采购结算、经销商结算、商场结算、O2O结算、跨企业主体结算、财务对账、结算风险管理等。

上面提到的众多系统都可以通过应用架构设计方法来进行设计，这里我们以渠道系统中的一个子系统——店铺系统为例，进一步看看通过领域建模方法构建应用架构中核心的领域模型和领域服务的过程。

图例：店铺子应用系统示例

首先，我们做准备工作，从业务架构的业务流程和业务能力出发。

店铺系统是电商平台的一部分，主要面向买家、卖家及平台运营者。这里对卖家进行分析，可以看到主要涉及注册、开店、店铺装修、店铺营销及店铺推广，同时我们从业务能力中识别了一些关键的业务活动，如注册时提交资质审核资料，开店时创建店铺等。

其次，我们初步分析出一些领域，包括店铺域、商品域、库存域、营销域等。

再次，我们进行领域模型的设计，结合DDD等方法，可以得出店铺基本信息、店铺类目、店铺库存、店铺商品、店铺装修、店铺运营等基本领域实体，并且建立它们之间及它们与其他领域模型的关系。

最后，我们根据DDD的上下文，对店铺域和其他域（如商品域、装修域、营销域）进行上下文分析，并建立各自的领域服务及彼此之间的交互关系。

在完成店铺应用系统的核心设计后，我们可以按照这个思路来构建其他应用，并逐步构建整体的企业应用架构。