上一篇我们讲了DDD的核心概念（附上链接），并且设计了我们的上下文映射图，那么接下来就准备开始立项了，本篇文章的部分知识点可能对一部分人来说比较基础，可以选择性的阅读。
在这之前我们平常用的最多的应该就是3层架构了，这里也不展开描述了，大家都是在3层的陪伴下一路走来的~
DDD所使用的传统分层架构是松散分层，也就是上层可以访问任意层级的下层，而不是仅限于当前层的下一层，这是有别于3层架构的。如下面2张图的区别图：
【图1】
【图2】
Application：这层的职责是对接收到的数据做一些非业务性验证，事务的控制，最重要的是协调多个聚合之间的操作。这里应该可以清晰的表达出整个操作所做的事情，并且与通用语言是一致的。
Domain：这一层是DDD设计的核心，这里不但需要精确合理的表达出通用语言的每一个细节，另外如何把对象合理的定义为聚合、实体、值对象也是重中之重。这里不但关系着整个项目的复杂度，也是战术建模的体现，任何的一行代码都是对业务的准确定义，应该是恰到好处。一个清晰简洁的战术建模才可以应对后续的快速变化。
Infrastructure：这里是辅助性的一层，也是整个项目的基础。好比这里存放着一砖一瓦，最终建造什么模样的高楼在于用它的地方。主要包括，仓储的实现（我们存放数据的地方）、一些通用的支撑性类库。
二、六边形架构
