一、思想概述
1.DDD为复杂软件设计提供了指导的思想，将易发生变化的业务核心放置在限定上下文（bounded context 有界域）中，在确保核心域一致性的和内聚性的基础上，DDD可以被多种语言和多种技术框架实现，具体框架实现需要根据实际业务场景和需求来制定。
核心的指导思路归纳为：
- 关注点放在domain（业务领域）上，将业务领域限定在同一上下文中，识别context bounded。
2.降低上下文之间的依赖，通过‘开放主机服务’（不要深究，就是网络通信服务，子系统与服务之间的通信协议，REST服务是其中的一种）、‘消息模式’、‘事件驱动’等架构风格实现
3.遵循分层架构模式
二、架构风格
针对DDD的架构设计，《实现领域驱动设计》有说到几种架构风格：六边形架构、REST架构、CQRS、事件驱动等。在实际使用中，落地的架构并非是纯粹其中的一种，而很有可能户将上述几种架构风格结合起来实现。
下面分别进行介绍和说明
1. 六边形架构
端口和适配器，六边形架构就是分层架构的拓展。原来的分层架构通常是上下分层的，比如常见的MVC模式，上层是对外的服务接口，下层是对接存储层或者是集成第三方服务，中层是业务逻辑层。我们跳出分层的概念，会发现上面层和下面层其实都是端口+适配器的实现，上面层开放http/tcp端口，采用rest/soap/mq协议等对外提供服务，同时提供对应协议的适配器；下层也是端口+适配器，只不过应用程序这时候变成了调用者，第三方服务或者存储层提供端口和服务，应用程序本身实现适配功能。
六边形架构其实可以说是将原来的分层架构比如MVC架构的换一种说法，但是在DDD思想中，使用六边形架构，让领域模型处于架构的核心，我们开发人员需要让领域模型处于架构的核心区域，让开发人员将焦点聚集到领域。DDD和六边形架构是天然契合的，是DDD的首选架构。看上图。
2.REST
REST——即Representational State Transfer的缩写，翻译过来是"表现层状态转化"。参考表现层状态转换 RestFul架构
概述: restful架构风格就是资源的表现层状态转换，一个资源就是由一个uri映射的数据（文字、图片、二进制）,表现层（就是资源的外在表现形式），状态转换（客户端与服务端通信时，资源的状态需要转换）
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
综合上面的解释，我们总结一下什么是RESTful架构：
（1）每一个URI代表一种资源；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
3. CQRS——Cammand-Query Responsibility Segregation的缩写。
翻译过来就是“[命令与查询职责分离]
(http://www.udidahan.com/2009/12/09/clarified-cqrs/)”。
简而言之，CQRS就是平常大家在讲的读写分离，通常读写分离的目的是为了提高查询性能，同时达到读/写的解耦。让DDD和CQRS结合，我们可以分别对读和写建模，查询模型通常是一种非规范化数据模型，它并不反映领域行为，只是用于数据显示；命令模型执行领域行为，且在领域行为执行完成后，想办法通知到查询模型。
那么命令模型如何通知到查询模型呢？ 如果查询模型和领域模型共享数据源，则可以省却这一步；如果没有共用数据源，则可以借助于‘消息模式’（Messaging Patterns）通知到查询模型，从而达到最终一致性（Eventual Consistency）。
Martin在blog中指出：CQRS适用于极少数复杂的业务领域，如果不是很适合反而会增加复杂度；另一个适用场景为获取高性能的服务。
4. 事件驱动
简单来说，事件驱动架构就是基于事件进行通信的软件架构，它具有以下的特点：
分布式异步架构，事件生产者和消费者高度解耦（生产者不知道有多少消费者要消费对应事件），事件消费者之间也高度解耦（消费者之间也互不感知）
更好的性能，由于事件的异步本质，软件不易产生拥堵，能够处理更高的流量。
事件处理器可以独立的开发，测试，部署，并容易接入到整个生态系统，故可扩展性好。
我自己没有现成的项目使用领域驱动设计的实例，下面使用网友分享的:
架构详述
COMMUNITY系统架构整合了六边形架构、RESTful架构风格、CQRS架构风格三种架构风格，并遵循经典的分层架构思想。
1、在遵循分层架构思想的基础上，引入了六边形架构风格，对内对外均通过适配器+端口的方式呈现：
面向用户侧，提供http端口，并使用SpringMVC框架的RequestMapping、Controller等组件实现对http 请求的解析，转化为Application层可识别的业务dto对象，这里的Controller+RequestMapping便起着适配器的作用；
面向第三方服务，通过httpclient和tcpclient的适配，可以对接多种协议的第三方服务端口；
面向存储层，通过mongoclient的适配，访问mongodb；通过mybatis的适配，访问oracle；通过redisclient的适配，访问redis；
面向消息中间件，通过mqclient的适配，方为rabbitMQ；
2、实现了RESTful架构风格，通过RESTful风格的接口契约对外提供主机开放服务。借助SpringMVC实现。
3、实现了CQRS架构风格：
orcale作为命令模型存储存在，并配以Transaction事务管理。主要存储帖子、评论、话题、圈子、关注等实体信息；
Mongodb作为查询模型存储存在，存储个人动态、社区动态等非结构化数据；
redis同样作为查询模型存储存在，存储用户个人信息、热门评论、热门帖子、热门话题、用户点赞信息等；
Application层分为QueryService和CommandService两大类应用服务，分别组合查询模型和命令模型；
使用rabbitMQ作为消息中间件，CommandService在完成命令模型的维护后，生产事件消息写入rabbitMQ，QueryService作为消费者从rabbitMQ读取事件消息，更新查询模型；
查询模型和命令模型极其对应的application service可以独立部署，独立扩展。
4、遵循基本的分层架构风格。
User Interface —— 用户接口层。对外提供各种协议形式的服务，并提供Validation参数校验，authenticate权限认证，业务实体组装器Assembler等。图中标绿组件。
Application —— 应用服务层。组合多个业务实体、基础设施层的各种组件完成业务服务。图中标黄部分。
Domain —— 业务领域层。DDD概念中的核心业务层，封装所有业务逻辑，包含entity、value object、domain service、domain event等。图中标蓝部分。
Infrastructure —— 基础设施层。提供公共组件，如：Logging、Trascation、HttpClient等。图中标灰部分。
上面的示例图希望大家可以好好参考下，值得大家好好琢磨，深入理解哈。
参考如下:
事件驱动架构
使用领域驱动设计思想实现业务系统
参考表现层状态转换 RestFul架构
待续。。。
