首先，这是一套DDD的框架，包含了其中的要素
其次，这是一套分布式框架，即，DDD的运作需要建立在分布式的基础之上。
另外，我们希望该框架足够开发，灵活，稳定，高效，可伸缩
该框架的整体架构暂定如下图：
该框架的基本设想如下：
我们将处理应用业务的部分称为内部，与之相对的，对应用外部提供的接口称之为外部接口，与客户端的地位等同，客户端也可建立在对外接口之上。
话说，一般来说，客户端应该只能建立在对外接口之上，我是赞同此观点的。但是，我为什么不这么做呢，因为不确定，我不确定我的对外接口能够满足一切服务总线提供的功能提供给客户端，
在这个不确定之上，我保留这个对外的口子，不过还是推荐奖客户端建立在对外接口之上。
内部的服务则是为了支撑起整个应用体系，为此，这里引入了企业服务总线（ESB）这个东西，以接触子系统之间的深度耦合，以期望该结构可以整体应用的可伸缩性上起到作用。
而搭载在总线上的内容，我们称之为节点。总线，和节点相互交织成网状结构，对外提供应用功能。
每个节点总是会被一层我们称之为防腐层的层次包围，该层次，我们希望它可以尽量的薄，它的作用为对外通讯，内容转换，使外部的数据结构不会腐蚀领域中的模型。
防腐层内部包裹的则为领域，领域这里则是经典的ddd中所提到的内容了，我们这里假设其主要有聚合跟，实体，值对象，领域事件，领域服务构成，另外很可能还需要仓储及查询的支持。
节点和节点之间的通讯，我们仅假设了两种方式，即命令与事件，值得注意的是，这里的事件和领域事件并不可以划等号，因为他们所在工作的层次不同。
接下来就是大量的基础设施了，他们是为了支撑这个架构而存在的，或许还会提供些许便利的功能。
对了，该框架目前依赖于这样两个框架：
structuremap 2.6.1.0 该框架提供IoC的功能，没有封装，与框架深度耦合，在短时间内也没有对该模块进行封装的打算
Shuttle 该框架的总线支持，由其提供。
log4net 该框架提供了日志基础功能。