DDD是什么？-优快云博客

本文链接：https://blog.youkuaiyun.com/foreverimps/article/details/145597093

领域驱动设计（DDD）中各个名词的详细解释：

领域（Domain）
- 定义：领域是一个特定的业务范围或主题区域，它代表了一个特定的业务领域，包含了该领域内的业务活动、规则、流程和知识等。可以将其看作是对现实世界中某一方面业务的抽象概念化。
- 示例：例如在医疗行业中，整个医疗业务就是一个领域，其中涵盖了疾病诊断、治疗方案制定、药品管理、患者护理等一系列相关的业务活动和知识。再如物流领域，包含了货物运输、仓储管理、配送调度等业务内容。
- 重要性：明确领域的边界和范围，有助于团队集中精力去深入理解该领域的业务需求和规则，从而为后续的软件设计和开发提供准确的方向和基础。
子领域（Subdomain）
- 定义：子领域是对一个大的领域进行细分后得到的更小的业务范围。每个子领域都有其相对独立的业务功能和逻辑，并且可以被看作是一个相对独立的模块或部分。
- 示例：在电商领域中，商品管理、订单管理、用户管理、支付管理、物流配送等都可以看作是电商领域的子领域。每个子领域专注于处理特定的业务功能，例如商品管理子领域负责商品的上架、下架、编辑、分类等操作。
- 重要性：通过将领域细分为子领域，可以降低系统的复杂性，使开发团队能够更加专注地处理每个子领域的业务逻辑，提高开发效率和系统的可维护性。同时，也有助于更好地组织和管理项目，明确各个团队或成员的职责范围。
核心域（Core Domain）
- 定义：核心域是领域中对企业业务成功起到关键作用的部分，它体现了企业的核心竞争力和独特价值，是企业区别于其他竞争对手的关键所在。
- 示例：对于一家在线旅游定制平台来说，其个性化的旅游线路规划和定制服务可能就是核心域，因为这是吸引用户并为企业带来核心收益的关键功能。对于一家网约车公司，高效的智能派单系统和优质的司机管理服务可能构成其核心域。
- 重要性：明确核心域可以帮助企业将资源和精力集中在最关键的业务部分，不断优化和提升核心域的功能和性能，以增强企业在市场中的竞争力。在软件设计和开发中，也能够围绕核心域进行重点设计和开发，确保核心业务的顺利实现。
支撑子域（Supporting Subdomain）
- 定义：支撑子域是为核心域提供必要支持和辅助功能的子领域，虽然它们不是企业的核心竞争力所在，但对于核心域的正常运行是必不可少的。
- 示例：在电商平台中，用户认证和授权功能就是一个支撑子域，它确保只有合法的用户能够访问和操作平台，为核心的交易业务提供安全保障。支付处理模块也是支撑子域，负责处理用户的支付操作，保障交易的顺利完成。物流跟踪服务同样属于支撑子域，为用户提供订单物流状态的查询功能，提升用户体验。
- 重要性：支撑子域的稳定运行是核心域能够正常发挥作用的基础。合理设计和管理支撑子域可以提高整个系统的可靠性和稳定性，使核心域能够更加专注地实现其核心业务功能。
通用子域（Generic Subdomain）
- 定义：通用子域是指在多个领域或项目中都可能被重复使用的功能模块，这些功能具有通用性和普遍性，不特定于某个具体的业务领域。
- 示例：日志记录功能是一个典型的通用子域，几乎在所有的软件系统中都需要记录系统的运行日志，以便进行故障排查和性能分析。文件存储功能也是通用子域，用于存储和管理系统中的各种文件，如图片、文档等。身份验证和权限管理中的一些基本功能也可以看作是通用子域，在不同的系统中都可能会用到。
- 重要性：将通用功能提取为通用子域，可以避免在每个项目中都重复开发这些功能，提高代码的复用性和开发效率，同时也有助于形成标准化的解决方案，便于不同项目之间的借鉴和使用，降低开发成本和维护成本。
领域模型（Domain Model）
- 定义：领域模型是对领域内的业务概念、实体、关系和规则的可视化表示，它以一种抽象的方式描述了业务领域的本质特征和内在逻辑，是业务领域的一种概念性表达。
- 示例：以图书馆管理系统为例，其领域模型可能包含图书实体、读者实体、借阅记录实体等。图书实体与读者实体之间存在借阅关系，借阅记录实体则记录了图书和读者之间的借阅行为和时间等信息。同时，还会有一些业务规则，如每个读者最多可借阅的图书数量、借阅期限等，这些都构成了图书馆管理系统的领域模型。
- 重要性：领域模型是连接业务人员和开发人员的重要桥梁，它帮助开发人员准确理解业务需求，将业务逻辑转化为软件实现。同时，领域模型也为系统的设计和架构提供了基础，指导代码的编写和模块的划分，确保软件系统能够准确地反映业务领域的实际情况。
实体（Entity）
- 定义：实体是领域模型中的一个关键概念，它是具有唯一标识符的对象，并且其状态会随着时间的推移而发生变化。实体通常代表领域中的具体事物或对象，这些事物或对象在业务领域中具有独立的身份和生命周期。
- 示例：在电商系统中，用户是一个实体，每个用户都有唯一的用户 ID 作为标识符，用户的个人信息（如姓名、地址、联系方式等）和购买行为等会随着时间的变化而改变。商品也是一个实体，每个商品有唯一的商品编号，其价格、库存数量等属性会随着销售和补货等操作而发生变化。
- 重要性：实体的设计能够准确地映射现实世界中的业务对象，使得系统能够有效地管理和操作这些对象的状态和行为。通过唯一标识符，能够确保实体的唯一性和可识别性，方便进行数据的存储、检索和更新，保证系统中数据的准确性和一致性。
值对象（Value Object）
- 定义：值对象用于表示那些没有唯一标识符、主要用于描述实体的属性或特征的对象。值对象通常是不可变的，一旦创建就不能被修改，如果需要修改其值，通常是创建一个新的值对象来替换原来的。
- 示例：在用户实体中，用户的地址可以是一个值对象，地址包含了省、市、区、街道等信息，它用于描述用户的居住位置，本身没有独立的唯一标识。当用户的地址发生变化时，通常是创建一个新的地址值对象来替换原来的。商品的颜色和尺寸也可以作为值对象，它们用于描述商品的属性，并且在创建后一般不会被修改。
- 重要性：值对象的使用可以简化实体的设计，将一些相关的属性组合在一起，提高代码的可读性和可维护性。同时，不可变性使得值对象在多线程环境下更加安全，避免了数据不一致的问题，并且在进行对象比较和传递时更加方便。
聚合（Aggregate）
- 定义：聚合是一组相关的实体和值对象的集合，它们作为一个整体被管理和操作。聚合有一个根实体，也称为聚合根，外部对象只能通过聚合根来访问聚合内部的其他对象，聚合内部的对象之间具有较强的一致性和关联性。
- 示例：在订单管理中，订单聚合可能包含订单实体（聚合根）、订单明细实体以及相关的值对象（如订单金额、下单时间等）。订单实体作为聚合根，外部系统只能通过订单实体来访问订单明细和其他相关信息，而不能直接访问订单明细实体。这样可以确保订单数据的一致性和完整性，例如在修改订单时，能够统一处理订单和订单明细的相关操作。
- 重要性：聚合的概念有助于界定领域模型中的边界和职责，将相关的对象组合在一起，形成一个相对独立的业务单元。通过限制外部对聚合内部对象的直接访问，保证了聚合内部数据的一致性和业务逻辑的完整性，同时也提高了系统的可维护性和可扩展性。
聚合根（Aggregate Root）
- 定义：聚合根是聚合的入口点，它是聚合中的一个特殊实体，负责维护聚合的一致性和完整性。外部系统只能通过聚合根来与聚合进行交互，而不能直接访问聚合内部的其他实体和值对象。
- 示例：继续以订单聚合为例，订单实体作为聚合根，当外部系统需要获取订单信息时，只能通过订单实体提供的接口来获取，而不能直接访问订单明细实体。在更新订单状态时，也是通过订单实体来协调订单明细和其他相关对象的状态变化，确保整个聚合的一致性。比如，当订单状态变为已发货时，订单实体可以通知相关的订单明细更新其发货状态等信息。
- 重要性：聚合根的存在使得聚合具有清晰的边界和访问控制，有助于简化系统的设计和维护。它保证了聚合内部数据的一致性，避免了外部直接操作聚合内部对象可能导致的数据不一致问题，同时也为系统的并发控制和事务管理提供了便利。
领域服务（Domain Service）
- 定义：领域服务是用于封装那些无法自然地归类到实体或值对象中的业务逻辑的组件。它通常涉及多个实体之间的协作或执行一些与领域相关的复杂计算，这些逻辑不属于某个特定实体的职责范围，但又与业务领域密切相关。
- 示例：在电商系统中，计算订单的优惠金额可能涉及到多个因素，如商品的原价、促销活动、用户的会员等级等。这个计算逻辑不能简单地归属于某个实体，因此可以将其封装在一个领域服务中。另一个例子是在物流系统中，安排货物的配送路线，需要考虑多个订单的收货地址、车辆的载重限制等因素，这也适合用领域服务来实现。还有在金融系统中，计算贷款利息、处理复杂的金融交易逻辑等都可以通过领域服务来完成。
- 重要性：领域服务的引入可以将复杂的业务逻辑从实体和值对象中分离出来，使实体和值对象更加专注于自身的属性和行为，提高代码的可读性和可维护性。同时，领域服务也方便对业务逻辑进行测试和修改，因为它们可以独立于实体和值对象进行单元测试，并且在业务规则发生变化时，只需要修改相应的领域服务即可。
仓储（Repository）
- 定义：仓储是一种设计模式，用于封装数据访问逻辑，提供对领域对象的存储和检索功能。它充当领域模型与数据持久化层（如数据库）之间的桥梁，使领域层与具体的数据存储技术解耦，使得领域层的代码不依赖于特定的数据库管理系统或数据存储方式。
- 示例：在一个基于数据库的应用系统中，对于用户实体，可以创建一个用户仓储接口，定义获取用户、保存用户、删除用户等方法。具体的实现类可以使用 SQL 语句或其他数据访问技术来操作数据库。这样，领域层中的其他组件（如应用服务、领域服务等）只需要调用用户仓储的方法来操作用户数据，而不需要关心具体的数据库操作细节。例如，应用服务在需要保存用户信息时，只需要调用用户仓储的保存方法，而不需要编写具体的 SQL 插入语句。
- 重要性：仓储模式的使用使得领域层与数据持久化层分离，提高了系统的可维护性和可扩展性。当需要更换数据存储技术（如从关系型数据库切换到 NoSQL 数据库）时，只需要修改仓储的实现类，而不会影响到领域层的其他部分。同时，仓储也有助于实现数据访问的统一管理和优化，提高数据访问的效率和性能。
工厂（Factory）
- 定义：工厂是一种创建对象的机制，用于封装对象的创建过程。当创建一个对象的逻辑比较复杂，或者需要根据不同的条件创建不同类型的对象时，使用工厂模式可以使对象的创建过程更加清晰和可控，将对象的创建逻辑从使用对象的地方分离出来。
- 示例：在游戏开发中，可能需要根据不同的游戏场景和玩家选择创建不同类型的角色对象。可以创建一个角色工厂类，根据传入的参数（如角色类型、初始属性等）来创建相应的角色对象。在电商系统中，创建订单对象时可能需要进行一些初始化操作，如设置订单编号、下单时间等，也可以使用订单工厂来封装这些创建逻辑。例如，订单工厂可以根据当前时间生成唯一的订单编号，并设置订单的初始状态为未支付等。
- 重要性：工厂模式将对象的创建逻辑从使用对象的地方分离出来，提高了代码的可维护性和可复用性。它使得对象的创建过程更加集中和可控，便于进行修改和扩展，同时也提高了代码的可读性，使代码的意图更加清晰。当对象的创建逻辑发生变化时，只需要修改工厂类的代码，而不会影响到使用对象的其他部分。
领域事件（Domain Event）
- 定义：领域事件是对领域中发生的重要事情的一种抽象表示，它用于通知其他部分领域模型发生了某个事件，从而触发相应的业务逻辑。领域事件通常包含事件的相关信息，如事件发生的时间、涉及的实体等，并且可以被其他组件订阅和处理。
- 示例：在电商系统中，当用户成功下单后，可以发布一个“订单已创建”的领域事件。其他模块（如库存管理模块、物流系统模块等）可以监听这个事件，当接收到该事件后，库存管理模块可以减少相应商品的库存数量，物流系统模块可以开始安排订单的配送。在银行系统中，当用户的账户余额发生变化时，可以发布一个“账户余额变动”的领域事件，用于通知相关的业务模块进行处理，如记录交易日志、发送通知给用户等。
- 重要性：领域事件的使用实现了领域模型中不同模块之间的解耦，使得各个模块可以独立地处理自己感兴趣的事件。它有助于实现业务逻辑的异步处理和分布式处理，提高系统的可扩展性和灵活性。同时，通过记录领域事件，可以实现系统的审计和追溯功能，便于了解系统的运行历史和业务操作的先后顺序。
限界上下文（Bounded Context）
- 定义：限界上下文是一个概念上的边界，在这个边界内，领域模型的术语、概念和规则具有明确的含义。不同的限界上下文之间可能存在语义上的差异，需要进行上下文映射来解决它们之间的交互问题。每个限界上下文可以看作是一个相对独立的业务领域或子系统，有自己的领域模型和业务逻辑。
- 示例：在一个大型企业中，销售部门和财务部门可能处于不同的限界上下文。在销售部门的限界上下文中，“订单”可能主要关注订单的销售情况、客户信息等；而在财务部门的限界上下文中，“订单”可能更关注订单的金额、收款情况等。这两个限界上下文中的“订单”概念虽然有一定的关联，但含义和关注点有所不同。为了实现两个部门之间的协作，需要进行上下文映射，明确两个限界上下文中“订单”概念的转换关系。
- 重要性：限界上下文的概念有助于明确领域模型的边界和范围，避免不同概念之间的混淆。它使得团队成员能够在一个相对清晰的范围内理解和应用领域模型，提高沟通效率和开发效率。同时，通过上下文映射，可以实现不同限界上下文之间的集成和协作，构建出更复杂的业务系统，并且能够更好地应对业务变化和系统扩展的需求。
上下文映射（Context Mapping）
- 定义：上下文映射是用于解决不同限界上下文之间语义差异和交互问题的机制。它描述了不同限界上下文之间的关系，以及如何在它们之间进行信息转换和共享。通过上下文映射，可以明确不同限界上下文中概念的对应关系，确保信息在不同上下文之间的准确传递和理解。
- 示例：在上述销售部门和财务部门的例子中，上下文映射可以定义销售部门的“订单”对象如何转换为财务部门所需的“订单”数据格式，包括哪些属性需要传递、如何进行数据转换等。例如，销售部门的订单包含客户的详细地址信息，但财务部门只需要客户的基本信息用于收款记录，上下文映射就可以规定只传递相关的基本信息，并进行相应的格式调整。
- 重要性：上下文映射是实现不同限界上下文之间有效协作的关键。它能够消除不同上下文之间的语义障碍，使得系统能够在多个限界上下文之间进行信息交互和共享，从而实现更复杂的业务流程和功能。在大型分布式系统中，上下文映射尤为重要，它有助于整合各个子系统，提高系统的整体性能和可维护性。
防腐层（Anti-Corruption Layer）
- 定义：防腐层是在不同限界上下文交互时，为保护本上下文领域模型不受外部影响而构建的隔离层。当一个限界上下文需要与另一个限界上下文进行交互时，通过防腐层可以将外部上下文的数据和接口转换为本上下文能够理解和处理的形式，防止外部上下文的变化对本上下文的领域模型造成直接影响。
- 示例：假设一个电商系统需要与第三方支付平台进行交互，第三方支付平台有自己的接口和数据格式，与电商系统的领域模型可能存在差异。为了保护电商系统的领域模型不受第三方支付平台接口变化的影响，可以在电商系统与第三方支付平台之间构建一个防腐层。防腐层负责将电商系统的支付请求转换为符合第三方支付平台

以下是一个以电商系统为例，将领域驱动设计（DDD）中的名词串联起来的详细示例，更好地理解它们在实际业务场景中的应用和相互关系：

假设我们要构建一个大型综合电商平台，这个平台涵盖了众多的业务功能和流程。

领域（Domain）：整个电商业务构成了我们的领域，它包括了从商品的采购、上架、销售，到用户的注册、购物、支付，再到商品的物流配送、售后服务等一系列相关的业务活动、规则和知识。例如，像淘宝、京东这样的大型电商平台，它们所涉及的业务范围就属于电商领域。
子领域（Subdomain）：为了更好地管理和处理复杂的电商业务，我们将电商领域细分为多个子领域。比如，商品管理子领域负责商品的录入、编辑、分类、审核等操作；订单管理子领域专注于订单的创建、跟踪、状态更新等；用户管理子领域处理用户的注册、登录、信息维护、会员等级管理等；支付管理子领域承担支付方式的管理、支付流程的处理、退款等业务；物流管理子领域则负责商品的仓储、运输、配送等环节。
核心域（Core Domain）：在这个电商系统中，商品的展示和销售以及用户的购物体验是核心域。因为这直接关系到平台的营收和用户的留存。例如，通过精准的商品推荐算法，为用户展示他们可能感兴趣的商品，促进购买行为；优化购物流程，减少用户的操作步骤，提高转化率，这些都是核心域的重要组成部分。
支撑子域（Supporting Subdomain）：用户管理子域为核心域提供了基础的用户信息管理和身份验证功能，确保只有合法的用户能够进行购物操作；支付管理子域保障了交易资金的安全流转，是购物流程得以顺利完成的关键支撑；物流管理子域则负责将商品及时、准确地送达用户手中，提升用户的满意度，这些都属于支撑子域，它们共同协作，保障核心域的正常运转。
通用子域（Generic Subdomain）：电商系统中存在一些通用的功能，可作为通用子域。比如日志记录功能，用于记录系统的各种操作日志、错误日志等，在各个子领域中都可能用到，方便后续的问题排查和系统分析；文件存储功能，用于存储商品图片、用户头像等文件，为不同的子领域提供统一的文件存储服务。
领域模型（Domain Model）：电商系统的领域模型是对整个电商业务的抽象表示，它由一系列的实体、值对象、聚合以及它们之间的关系和业务规则组成。例如，商品实体、用户实体、订单实体等相互关联，共同构成了描述电商业务的领域模型。
实体（Entity）：
- 用户实体：具有唯一的用户 ID，是用户在电商系统中的标识。用户的姓名、联系方式、收货地址、会员等级等信息构成了用户实体的属性，这些属性会随着用户的操作而发生变化。比如，用户修改了自己的收货地址，那么用户实体中的收货地址属性就会更新。
- 商品实体：以唯一的商品编号作为标识，商品的名称、描述、价格、库存数量、品牌等属性构成了商品实体。当商品进行销售或补货时，商品实体的库存数量和价格等属性会相应地改变。
- 订单实体：拥有唯一的订单号，订单的创建时间、下单用户、订单状态（如待付款、已付款、已发货、已完成、已取消等）、订单金额等属性组成了订单实体。随着订单处理流程的推进，订单实体的状态会不断变化。
值对象（Value Object）：
- 用户地址值对象：作为用户实体的一部分，用于描述用户的收货地址，它包含省、市、区、街道、邮编等信息。用户地址值对象本身没有独立的唯一标识，当用户的地址发生变化时，通常是创建一个新的地址值对象来替换原来的。
- 商品价格值对象：表示商品的价格，是商品实体的一个属性。商品价格值对象通常是不可变的，一旦确定，在某个特定的时间段内不会随意更改，除非有特殊的价格调整操作。
聚合（Aggregate）：以订单聚合为例，它是一组相关的实体和值对象的集合，包括订单实体（聚合根）、订单明细实体以及一些相关的值对象，如订单总金额、下单时间等。这些对象紧密相关，共同构成了一个完整的订单业务单元，并且作为一个整体被管理和操作。
聚合根（Aggregate Root）：订单实体作为订单聚合的聚合根，是外部访问订单聚合的唯一入口。外部系统只能通过订单实体来获取订单的详细信息，如订单明细、订单状态等，而不能直接访问订单聚合内部的其他实体。同时，订单实体负责维护订单聚合的一致性和完整性。例如，当订单状态发生变化时，订单实体要确保订单明细和其他相关对象的状态也相应地进行更新。
领域服务（Domain Service）：
- 计算订单优惠服务：在电商系统中，计算订单的优惠金额是一个复杂的业务逻辑，它涉及到用户的会员等级、商品的促销活动（如满减、折扣券、限时优惠等）以及平台的优惠策略等多个因素。这个逻辑无法简单地归属于某个实体，因此将其封装在一个领域服务中。领域服务根据这些因素综合计算出订单最终的优惠金额，并返回给相关的业务流程。
- 库存管理服务：当用户下单购买商品时，需要更新商品的库存数量；当有新的商品进货时，也需要增加库存数量。这个涉及到商品实体和订单实体之间的协作逻辑，通过库存管理服务来实现。库存管理服务会根据订单的商品数量和进货单的商品数量，准确地更新商品的库存状态。
仓储（Repository）：
- 用户仓储：负责对用户实体的存储和检索操作。它定义了一系列方法，如根据用户 ID 获取用户信息、保存新用户的注册信息、更新用户的个人信息、删除用户等。具体的实现可以使用数据库操作，例如通过 SQL 语句从用户表中查询或插入数据。
- 商品仓储：用于存储和检索商品实体。提供了获取商品（根据商品编号、名称等条件）、保存商品（上架新商品或更新商品信息）、删除商品（下架商品）等功能。通过商品仓储，领域层可以方便地与数据持久化层进行交互，而无需关心具体的存储技术和实现细节。
工厂（Factory）：订单工厂负责创建订单对象。在创建订单时，需要进行一系列的初始化操作，如生成唯一的订单编号、设置订单的创建时间、默认订单状态为“待付款”、关联下单用户等。订单工厂根据这些规则和逻辑，创建出完整的订单对象，并返回给调用方，例如在用户确认购买商品并提交订单时，订单工厂就会创建一个新的订单对象。
领域事件（Domain Event）：
- 订单创建事件：当用户成功提交订单后，系统会发布一个“订单已创建”的领域事件。其他相关的模块，如库存管理模块、支付管理模块等可以监听这个事件。库存管理模块接收到该事件后，会根据订单中的商品数量减少相应商品的库存；支付管理模块则会启动支付流程，引导用户进行付款操作。
- 商品库存不足事件：当某商品的库存数量低于设定的阈值时，系统会发布“商品库存不足”的领域事件。商品管理模块监听该事件后，会触发补货流程，通知采购人员进行商品采购；同时，也可能会在商品详情页面显示库存紧张的提示，提醒用户尽快购买。
限界上下文（Bounded Context）：电商系统中存在多个限界上下文，每个限界上下文都有自己独立的领域模型和业务规则。例如，商品管理限界上下文专注于商品的相关业务，包括商品的录入、审核、分类等；订单管理限界上下文主要处理订单的创建、状态流转等；支付管理限界上下文负责支付相关的业务逻辑。不同限界上下文之间的术语和概念可能存在差异，需要进行上下文映射来实现它们之间的交互。
上下文映射（Context Mapping）：以商品管理限界上下文和订单管理限界上下文为例。在订单管理限界上下文中创建订单时，需要从商品管理限界上下文中获取商品的详细信息，如商品名称、价格、库存等。上下文映射定义了如何从商品管理限界上下文的商品实体中提取和转换这些信息，以适应订单管理限界上下文的需求。例如，将商品管理限界上下文中的商品价格转换为订单管理限界上下文中订单明细的商品单价，并进行相应的金额计算。
防腐层（Anti-Corruption Layer）：当电商系统与第三方支付平台进行交互时，由于第三方支付平台有自己独立的接口和数据格式，与电商系统的领域模型可能不兼容，所以需要构建一个防腐层。防腐层负责将电商系统的支付请求（按照电商系统的领域模型格式）转换为符合第三方支付平台要求的格式，同时将第三方支付平台返回的支付结果（以其特定格式）转换为电商系统能够理解和处理的形式。这样可以保护电商系统的领域模型不受第三方支付平台接口变化的影响，确保支付流程的稳定运行。
领域专家（Domain Expert）：在电商系统的开发过程中，领域专家可以是具有丰富电商运营经验的人员，如资深的商品采购经理、物流专家、市场营销专家等。他们对电商业务的各个环节有着深入的了解，能够为开发团队提供专业的业务知识和指导。例如，商品采购经理可以帮助确定商品的分类标准和上架规则；物流专家可以提供关于物流配送流程和优化的建议，从而协助开发团队构建更准确、更符合实际业务需求的领域模型。
通用语言（Ubiquitous Language）：在电商系统的开发团队中，包括业务人员、开发人员、测试人员等在内的所有成员，共同使用一套通用语言来描述电商业务。例如，“商品 SKU”“购物车”“优惠券”“订单取消”“退换货”等术语，大家都能准确理解其含义，并且在沟通和交流中使用这些术语，避免了因语言理解差异而导致的误解和沟通障碍，提高了团队的协作效率。
分层架构（Layered Architecture）：电商系统采用分层架构，一般分为表现层、应用层、领域层和基础设施层。
- 表现层（Presentation Layer）：主要负责与用户进行交互，展示商品信息、订单详情、购物车内容等界面，并接收用户的操作输入，如点击购买按钮、填写收货地址等。它可以是网页界面、手机应用客户端等形式。
- 应用层（Application Layer）：协调领域层的服务，处理业务流程中的事务。例如，当用户提交订单时，应用层会调用领域层的订单创建服务，并处理相关的业务逻辑，如检查库存、计算价格等。同时，应用层还为表现层提供接口，将处理结果返回给表现层进行展示。
- 领域层（Domain Layer）：实现电商业务的核心逻辑，包含了各种领域模型（实体、值对象、聚合等）、领域服务和领域事件等。如商品的库存管理逻辑、订单的状态转换规则等都在领域层实现，它是电商系统的核心部分，体现了业务的本质和规则。
- 基础设施层（Infrastructure Layer）：为整个系统提供技术支持，包括数据持久化（如使用数据库存储用户、商品、订单等数据）、消息队列（用于发布和订阅领域事件）、与外部系统的集成（如与第三方支付平台、物流跟踪系统的对接）等功能。基础设施层确保了系统的稳定运行和与外部环境的交互能力。