ddd：五层架构

• DCI架构

DCI是数据Data 场景Context 交互Interactions的简称
DCI是一种特别关注行为的模式(可以对应GoF行为模式)
而MVC模式是一种结构性模式，MVC模式由于结构化，而可能忽视了行为事件

User Interface是用户接口层，主要用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给Application层的接口
Application层是应用层，负责多进程管理及调度、多线程管理及调度、多协程调度和维护业务实例的状态模型；
    当调度层收到用户接口层的请求后，委托Context层与本次业务相关的上下文进行处理
Context是环境层，以上下文为单位，将Domain层的领域对象cast成合适的role，让role交互起来完成业务逻辑
Domain层是领域层，定义领域模型，不仅包括领域对象及其之间关系的建模，还包括对象的角色role的显式建模
Infrastructure层是基础实施层，为其他层提供通用的技术能力：业务平台，编程框架，持久化机制，消息机制，第三方库的封装，通用算法

• 架构

└── demo
    ├── application    
    |   ├── assembler   
    	 |   ├── dto    
    |   ├── event
    |   |   ├── publish  
    |   |   └── subscribe  
    |   └── service     
    |
    ├── context	# 环境层
    |
    ├── domain    
    |   ├── object
    |   |	 ├── aggregate1     
    |   |   └── aggregate2 
    |   |
    |   └── role
    |   	 ├── role1  	# 接口 + 实现类
    |       └── role2 
    |
    ├── infrastructure    
    |   ├── config
    |   ├── common
    |   └── uitl
    |
    └── interfaces    
        ├── validator   
             ├── handler   
        ├── assembler       
        ├── vo
        └── facade     

• 个人理解

context相当于应用层，object相当于领域层
role：显式地对领域对象（Object）在每个业务场景（Context）中扮演（Cast）的角色（Role）进行建模
    Role代表了领域对象在业务场景中的业务行为（“做什么”），Role之间通过交互完成完整的义务流程
    对Role的建模应该是面向Context的，我们就能够将领域对象的方法拆分出去
    在role中编写领域对象的具体业务，context则是对业务逻辑的的编排

• 上帝类

上帝类就是包含了太多的职责的实体类
上帝类违反了单一职责原则，会导致代码的可维护性变得极差