供应链商品域的DDD实践 -- 知识铺

在现代软件工程中，随着业务需求的不断增长和变化，软件系统的复杂性日益增加。领域驱动设计（Domain-Driven Design, DDD）作为一种应对复杂性的方法论，越来越受到重视。本文将从软件复杂性的来源、DDD的重要性以及其核心概念三个方面进行阐述。 一、软件复杂性的来源

软件复杂性主要源自以下几个方面：

1. 理解力挑战：需求规模庞大，业务类型繁多，相互耦合，导致系统复杂度增加。例如，供应链涉及多个行业和商业模式，系统间边界划分不清晰，依赖关系复杂。
2. 不可预测性挑战：商业环境和流程的快速变化使得软件系统设计难以一劳永逸。例如，国际化、智能商业路由等新兴需求的出现，对软件设计提出了新的挑战。
3. 协作力挑战：需求往往涉及多个团队，需求传递和沟通效率低下，缺乏统一的业务语言，导致理解上的偏差。

二、DDD的重要性

DDD通过设计合适的领域模型来映射现实业务，解决核心复杂问题。它的优势在于：

• 分而治之：通过控制规模，有效管理复杂性。
• 关注点分离：将领域模型与存储模型分离，业务与技术分离，应对理解力挑战。
• 分层架构：通过分层架构和核心分离，保持系统结构的清晰，应对不可预测性。
• 统一语言：通过建立统一的业务语言，提高团队间的沟通效率，减少理解偏差。

三、DDD的核心概念 DDD的实施包括以下几个核心概念： 1. 通用语言：建立团队成员之间的共同语言，确保概念和模型的一致性。 2. 分层架构：将系统分为不同的层次，每层关注不同的职责。 3. DDD要素：包括实体、值对象、聚合、领域服务等，它们是构成领域模型的基础。 4. 边界上下文：定义系统的边界，明确不同上下文之间的关系和交互。 通过DDD的实施，可以更好地应对软件复杂性，提高系统的可维护性和可扩展性。 通用语言是一种在特定领域内提炼和共享的沟通工具，它对于团队协作和项目开发具有至关重要的作用。以下是对通用语言的详细阐述： 1. 定义与作用：通用语言是团队成员在需求分析过程中达成共识的结果，它帮助不同背景的成员理解彼此的观点，并确保对系统目标、范围和功能有统一的认识。 2. 领域语言的特点：领域语言是团队专有的，由领域专家、产品经理和开发人员共同护。尽管在团队内部概念名称相同，但离开团队后，其含义可能完全不同。 3. 团队协作：通用语言是连接领域专家和技术人员的桥梁，它促进了跨领域的有效沟通。 4. 文档与沟通：在编写文档和日常沟通中，保持概念的一致性至关重要。特别建议创建中文对照表，将概念名称与代码实现相对应，以减少混淆。 5. 通用语言的价值： - 定义公共术语，避免概念混淆。 - 通过沟通达成共识，消除歧义和理解偏差，提高需求理解和知识传递的效率。 - 概念与代码的统一，加强了概念与实现之间的联系。 6. 实施建议：为了实现通用语言的最大化效益，建议在团队中推广以下实践： - 定期举行术语定义会议，确保所有成员对关键术语有共同的理解。 - 在项目文档中明确列出术语和定义，便于新成员快速上手。 - 在代码中使用与文档一致的术语，确保概念与实现的一致性。 7. 总结：通用语言是团队协作的基石，通过明确和一致的术语使用，可以显著提高团队的工作效率和项目的质量。 在领域驱动设计（DDD）中，分层架构是其核心概念之一，它强调模型的分离和关注点的独立。一个优秀的架构设计应该具备以下特点： 1. 关注点分离：将不同的功能和职责明确区分开来，使得系统更加清晰和易于管理。 2. 可维护性：由于关注点的分离，各个部分可以独立更新和维护，提高了系统的可维护性。 3. 可测试性：分离的架构使得对各个部分进行单元测试变得更加容易，有助于提高软件质量。 正如在日常生活中，当一个人同时处理多项任务时，很容易出现混乱和效率低下的情况。在软件开发中，如果一段代码承担了过多的职责，也会导致代码难以理解和维护。因此，我们需要将代码分解，使其专注于单一职责，从而提高整体的代码质量和开发效率。 分层架构通常包括以下几个层次： - 用户界面层：负责与用户交互，展示数据和接收用户输入。 - 应用层：处理应用程序的业务逻辑，协调不同层之间的交互。 - 领域层：包含业务规则和业务实体，是系统的核心。 - 基础设施层：提供技术实现，如数据库访问、消息传递等。 通过这种分层的方式，我们可以将复杂的系统分解成多个可管理的部分，每个部分专注于解决特定的问题，从而实现高效、可维护的软件开发。

商品域领域模型，在分层架构中的位置，如下：

在软件架构设计中，CQRS（Command Query Responsibility Segregation）模式是一种将读（Query）和写（Command）操作分离的策略。在这种模式下，领域模型主要负责处理命令，而查询和搜索服务则不通过领域模型实现，以提高系统的灵活性和可维护性。 隧道层（tunnel层）是应用架构中的一个关键部分，它负责与数据库和外部数据资源的交互，实现了领域模型与数据访问的解耦，这与数据访问对象（DAO）模式相似。 外部系统与领域模型的交互通常通过SPI（Service Provider Interface）实现，这是一种适配器模式，允许系统以灵活的方式与外部服务进行交互，类似于六边形架构中的适配器。 领域驱动设计（DDD）是一种软件开发方法，它强调以业务领域为中心进行软件开发。DDD中有几个关键要素： 1. 实体：具有唯一标识符（ID）、生命周期和状态的领域对象。它们拥有属性和行为，能够响应外部事件，触发状态或行为的变化。 2. 值对象（VO）：与实体不同，VO的属性是不可变的，通常使用final修饰。VO用于简化模型，通过将描述性属性分组封装，提高模型的表达力和结构化。 3. 服务：服务层负责处理跨实体的操作，如批量操作和实体间的交互，例如商品复制和资金转账。 在商品域的工程架构中，服务层的职责包括实体的创建、持久化以及跨实体的操作。不同层使用不同的数据对象，隧道层使用面向存储的数据对象，这些对象需要与领域实体进行转换。领域实体之间可以有动态加载的关联关系，而数据对象通常只包含数据，没有行为，也不具备关联关系。 这种分层和解耦的架构设计，有助于提高系统的可扩展性、可维护性和灵活性。 在探讨边界上下文的概念时，我们首先需要明确几个核心要点。边界上下文可以被理解为一个特定的领域或子领域，它定义了领域对象的准确含义。一旦超出这个边界，领域对象的含义可能就会发生变化，例如日常生活中的“苹果”，在不同的领域可能指代不同的事物。 边界上下文的概念同样适用于语言的使用。语言本身是具有上下文性的，不同的语境下，相同的词汇可能表达不同的含义。此外，人们在不同的边界上下文中扮演着不同的角色，承担着不同的职责和任务。例如，一个人在家中可能是父亲，在公司可能是员工，这两种角色所对应的职责和任务是截然不同的。 总结来说，边界上下文是一个重要的概念，它帮助我们理解领域对象的限定性，语言的多样性以及个体在不同环境下角色的多样性。 在探讨一个领域如何发挥其价值时，我们首先要认识到，一个封闭的系统是难以产生价值的。领域需要与外界进行交互，才能实现其价值的输出。以下是一些常用的方法来实现这一目标： 1. 共享内核：这是一种通过共享核心功能来实现不同领域间协同工作的方式。共享内核可以确保不同领域在保持独立性的同时，能够访问到共同的资源和功能。 2. 防腐层：这是一种保护领域模型不受外部变化影响的技术。具体来说，当外部系统需要与领域模型交互时，不是直接暴露领域模型，而是通过一个转换层来实现。这样，即使外部系统发生变化，也不会直接影响到领域模型的稳定性。 以采购域为例，当商品上游系统提供SPI（Service Provider Interface）时，采购域会建立一个防腐层。这个防腐层的作用是接收商品上游的变更信息，并将其转换为适合采购域内部使用的形式，从而减少商品上游变更对采购域的影响。 通过上述方法，我们可以确保领域在保持其独立性的同时，也能够有效地与外界进行交互，从而实现其价值的输出。 领域驱动设计（Domain-Driven Design, DDD）是一种软件开发方法论，其核心在于通过领域模型来解决复杂问题。然而，在实施DDD的过程中，我们会遇到一些挑战。以下是对这些挑战的梳理和分析： 1. 领域知识的识别与模型化：在DDD实施中，首先需要识别和提炼领域知识，并将这些知识转化为模型代码。这一步骤至关重要，因为它直接影响到软件能否准确反映业务需求和逻辑。 2. 模型的持续演进：随着业务的发展，领域模型需要不断地进行演进和优化。这要求开发团队持续投入，以保证DDD的实践能够持续有效地进行。 3. 团队思维的转变：DDD的实施还涉及到团队成员思维模式的转变。开发人员需要从传统的编程思维转向领域驱动的思维，这不仅是技术上的挑战，更是思维方式的变革。 这些挑战的克服，需要团队的共同努力和持续的实践。通过不断的学习和实践，可以逐步提高DDD实施的效果，从而更好地服务于业务需求。

2  什么是领域知识？

领域知识有分层分类，平台通用商业规则，是领域模型主要输入，商家个性化不能下沉到领域模型层。

在进行领域知识提炼和需求分析时，我们采用两阶段分析法，即用户故事和链路5W1H分析法。以下是对这一过程的详细阐述： 第一阶段：用户故事分析 用户故事分析聚焦于前3W，即Who（谁）、What（什么）、Why（为什么）。此阶段的目的是理解用户的基本需求和动机。例如，用户故事可能是：“作为采购小二，我需要商品库存为0时自动下架，以避免超卖风险，减少客户投诉。” 第二阶段：链路和边界分析 链路和边界分析则关注When（何时）、Where（何地）、How（如何）。此阶段旨在明确触发条件、涉及的领域以及各领域需提供的能力。例如，若要实现商品库存自动下架功能，我们需要考虑以下问题： - When：触发自动下架的条件是什么？ - Where：哪些环节或系统需要参与此功能？ - How：各环节或系统如何协同工作以实现需求？ 通过这两个阶段的分析，我们能够全面获取用户需求，并明确全链路的分工和协作方式，确保需求得到有效满足。 注意： - 用户故事应简洁明了，直接反映用户的需求和动机。 - 链路分析要细致，确保每个环节都能为实现需求贡献力量。 - 分析过程中要不断回顾和调整，确保分析结果的准确性和实用性。

4  领域知识提炼，结构化分析

• APP层至上而下过程分析，模型层自下而上分析相结合。

• 能力下沉保持模型不断演进，能力下沉标准：复用、内聚。

5  思考方式的转变

领域驱动，在模型阶段不会关注数据设计、不会关注存储、不会关注消息怎么发，业务和技术视角关注点做了分离。

五  商品域实践相关

商品域工程架构：

最后，保持模型不断演进！！！

商品域模型更新readme，保持模型不断演进。否则会APP层会越来越大，模型层越来越小，最后头重脚轻，领域坍塌了。

《微服务实战技术图谱》是由微服务领域的专家组精心打造的课程，它基于目前广受欢迎的微服务技术栈，如Spring Cloud Alibaba和Nacos。本课程汇集了阿里巴巴工程师的丰富实战经验，深入探讨了微服务架构中的关键技术点，包括但不限于服务发现、服务配置、服务调用、服务熔断以及Service Mesh等。通过本课程的学习，您将能够系统地掌握微服务架构的构建和应用，提高在实际工作中解决相关问题的能力。点击下方链接，立即开始您的微服务技术学习之旅。