了解DDD方法论的基本思想，以及常用的基本概念和分层架构。
目录
- DDD方法论的基本思想
- 基本概念
- 分层架构
- 调用链路
DDD方法论的基本思想
领域驱动设计（Domain-Driven Design, DDD）是一种针对复杂业务场景的软件开发方法论，它倡导通过紧密合作的业务和技术团队共同深入理解业务领域，并将这种深刻的理解转化为有效的软件设计。
基本思想主要包括以下几个方面：
-
领域为中心：DDD强调以业务领域为核心进行软件设计，通过对业务领域的深度挖掘，把握核心业务概念、规则及流程，使软件设计更贴合业务需求。
-
领域模型：构建领域模型是DDD的核心工作之一，模型是对业务领域内实体、值对象、聚合、领域事件等概念的抽象表达，体现了领域内的实体间关系和业务逻辑。
-
界限上下文（Bounded Context）：将复杂的业务领域划分为一系列具有明确边界的子领域，每个子领域内部有独立的领域模型，通过清晰的接口与其他上下文协同工作。
-
统一语言（Ubiquitous Language）：提倡在开发团队与业务专家之间建立一套共同的语言，减少沟通误解，确保模型准确反映领域知识。
基本概念
-
实体（Entity）：具有唯一标识并在生命周期中保持稳定身份的对象，即使属性变化也不影响其身份。
-
值对象（Value Object）：仅由其属性值定义的对象，没有独立标识，通常用来描述实体的一部分特征。
-
聚合（Aggregate）：一组相关对象的集群，有一个称为聚合根的实体对其进行统一管理，确保事务内的一致性。
-
领域服务（Domain Service）：封装不属于任何单一实体或值对象的业务逻辑，跨越多个实体或值对象执行操作。
-
领域事件（Domain Event）：表示领域内发生的重要业务事实，可用于异步通知、领域状态变更传播等。
分层架构
在DDD实践中，常用的分层架构主要有以下几层：
-
用户界面层（Presentation Layer）：负责用户交互，显示信息和收集用户输入。
-
应用层（Application Layer）：作为领域层与外部世界的桥梁，协调领域对象完成业务用例，不包含业务逻辑。
-
领域层（Domain Layer）：包含了核心的领域模型，持有业务规则和复杂业务逻辑，是最贴近业务的部分。
-
基础设施层（Infrastructure Layer）：提供底层技术支持，如数据库访问、网络通信、日志记录等，为上层提供透明的服务。
各层之间遵循依赖倒置原则，即上层只依赖于下层的接口，而不依赖于具体实现，确保了架构的灵活性和可扩展性。同时，DDD在微服务架构中也有广泛应用，每个微服务可以对应一个界限上下文，内部同样采用类似的分层架构。
调用链路
迄今为止最完整的DDD实践。1
章磊 阿里云开发者 ↩︎
