定义
DDD是Domain driven design（领域驱动设计）的简称，是一种软件设计和开发的方法论，特别适用于复杂业务领域软件设计和开发
核心
将所有业务逻辑内聚到业务领域（domain）层，将设计和开发的关注点聚焦到业务领域
战略上：上下文(Bounded Context)、防腐层(Anticorruption Layer)、开放主机服务
战术上：entity\value object\Aggregate\root entity\domain service\factory\repository\domain event
战略上，通过上下文（Bounded Context）解耦各个业务系统/组件，通过防腐层（Anticorruption Layer）确保各自业务领域不受外界污染，通过开放主机服务（Open Host Service）向外界提供服务。
战术上，将业务对象建模为entity和value object，entity有唯一业务标识且在其生命周期中状态可变，value object与之相反；关联性强的entity和value object聚合成一个Aggregate，每个Aggregate有一个root entity，确保Aggregate内容业务规则和行为的一致性；业务行为尽量建模在entity/ value object 上，当业务行为无法建模到任何业务entity/value object时，可以使用领域服务（domain service）；使用factory创建复杂的业务entity，使用repository实现实体的重建和持久化操作；领域相关的通知等可以通过domain event发布出去。
概念
Bounded context：边界上下文
划分领域边界，边界内领域模型保持一致，强调内聚，并与边界外的领域模型解耦
Entity：领域实体
有唯一标识，可变的业务实体对象，有自己的生命周期，如User等
Value Object：领域值对象
没有唯一标识，通常依附于领域实体，值对象的内容不可变 ，要么被整体替换
Aggregate：聚合
是一组业务关联度很强的实体/值对象的集合，每个聚合都有一个根实体（root entity），通过根实体可以路由到整个聚合
Domain Event：领域事件
领域内发生的异步处理事件、异步消息通知等，比如异步写入的登录日志，通常借助消息队列实现
Domain Service：领域服务
当某一类业务行为无法归类到实体/值对象时，可以创建领域服务来完成。比如账户转账场景，涉及两个Account实体；再比如社区敏感词过滤场景，帖子可以用、评论也可以用，因此可以抽离到ContentFilter完成
Repository：仓库
严格意义上讲，仓库是基础设施层的东西，但为了保持领域模型的完整性，将仓库的接口定义放到领域中，可以在领域内约束实体/值对象的行为，还可以方便地完成仓库的内存形式实现，使得领域模型弱依赖于持久化层。这一点在书中被称为“依赖倒置”（参考《实现领域驱动设计》P372）。
Factory：领域对象工厂
用于复杂领域对象的创建和重建，重建是指通过repository加载持久化对象后，重新创建领域对象
图解分层
User Interface——用户界面层：提供与用户/界面交互的接口，可以是restful api，也可以是view，或者二进制形式的tcp协议接口等
Application——应用服务层：组合Domain和Infrastructure，完成具体的业务逻辑
Domain——业务领域层：是DDD中的核心层，内聚所有的业务逻辑，保持领域的一致性。需要用到Infrastructure的基础组件
Infrastructure——基础设施层：提供公共服务组件，比如validation、登录态校验、日志记录等
架构风格
针对DDD的架构设计，《实现领域驱动设计》提到了几种架构风格：六边形架构、REST架构、CQRS、事件驱动等。在实际使用中，落地的架构并非是纯粹其中的一种，而很有可能户将上述几种架构风格结合起来实现
六边形架构
端口和适配器
框架实现
User Interface层
门面层，对外以各种协议提供服务，该层需明确定义支持的服务协议、契约等，包括dto和controller
dto
包括request和response两部分，定义出错和入参的契约，可以调用基础设施层的validation组件完成入参格式校验
facade\controller——控制器
支持不同访问协议的控制器实现，比如：http/restful协议、tcp协议、mq消息/json对象等，包括但不限于：
• 调用RequestMapping完成Servlet路由
• 调用checkLogin完成登录态和权限认证
• 调用logging组件完成日志记录
assembler——组装器
负责将多个不同的领域对象组装成dto对象，比如查询帖子列表，需要从帖子（领域对象）中获取帖子的详情，还要从用户（领域对象）中获取用户的基本信息
实现DTO与领域对象之间的相互转换,数据交换，因此Assembler几乎总是同DTO一起出现
不能有业务逻辑，主要负责格式转换、字段映射等
Application层
包含service和assembler
service——应用服务层
对外，组合domain层的领域对象和基础设施层的公共组件，根据业务需要包装出多变的服务
• 访问domain层的领域对象
• 访问infrastructure的公共组件，比如消息组件等
task——逻辑任务
对内，调用领域层（领域对象或领域服务）完成各种业务逻辑任务(task)
Domain层
高内聚的业务领域层，所有的业务逻辑都在这里
domain entity——领域实体对象
有唯一标识，可变的业务实体对象，业务实体有自己的生命周期，比如社区这个业务领域中，“帖子”就是一个业务实体，它的内容和状态可以不断发生变化。
domain value object——值对象
可以没有唯一性的业务标识，通常是短暂的，与java中的值对象（基本类型和String类型）类似。比如帖子的置顶信息可以理解为一个值对象，不需要为它定义独立的业务唯一性标识，只需要用帖子id，还有置顶状态和置顶位置，一旦任何一个属性值发生变化，重建值对象并赋值给帖子实体引用。
domain factory——对象工厂
用于复杂领域对象的创建/重建。重建是指通过repository加载持久化对象后，重建领域对象
domain service——领域服务，区别与Application层的service，属于业务领域服务
任何无法归类给领域实体和值对象的行为，都可以为它创建独立的领域服务，比如转账服务，需要操作借方/贷方两个业务实体。传统意义上的util类中static方法，涉及业务逻辑的，都可以归入domain service
domain event——领域事件
领域中一些消息事件，通过事件通知和订阅的方式，可以在性能和解耦方面提供非常大的好处
repository——仓库
与domain entity紧密联系，通过与基础设施的持久化层交互后 ，完成领域对应的增删改查操作
根据不同业务场景，仓库的实现，可以是reids、数据库、mongodb等
translator（翻译器，一般可以没有这一层）
将持久化的对象翻译成统一领域对象，不应该有业务逻辑，负责格式转换、字段映射等。
作用等同于Application层中的转换器 assembler
Infrastructure层
公共基础组件，供User Interface中的controller、Application层中的service、以及整个Domain层调用
repository impl
对domain层repository接口的实现，对应每种存储介质有其特定实现，如oracle的mapper，mongodb的dao等等。repository impl会调用mybatis、mongo client、redis client完成实际的存储层操作。
authorization 权限认证
提供给User Interface层的Controller调用。
exception 异常处理
提供公共的异常处理逻辑
logging 日志记录
日志模块
transport 传输器
transport完成和第三方服务的交互，可以有多种协议形式的实现，如http+json、tcp+自定义协议等，配套使用的还有Resolver解析器，用于对第三方服务的请求和响应进行适配，提供一个防腐层（AnticorruptionLayer）的作用
transaction 事务管理
事务管理，一般交给Spring管理
DDD的框架实现示意图
转载自：https://www.cnblogs.com/daoqidelv/p/7492322.html