领域区域设计的分层架构模型其实是在不断优化和发展的，从最早的传统直肠子式的四层架构模型，逐渐演变成目前以依赖倒置为原则的新的四层架构模型，从而实现了各层对基础设施层的解耦。
DDD中的分层架构很好的应用了关注点分离原则Separation of Concerns（SOC）,每一层做好自己的事情，减少交叉。
表现层
表现层也可以称作接口层，提供用来完成任务的用户界面或接口，负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。
一般而言，我们把表现层显示的任何数据称为视图模型，把任何从屏幕离开触发一个后台操作的数据称为输入模型，大多数时候这两个模型是相同的。
就分层应用程序而言，MVC，MVP，MVVM都是表现层的模式。
应用程序层
应用程序层是一个附加层，介于领域层和UI之间，是编排用例实现的地方，其中包含的方法几乎一一对应于表现层的用例。
一般情况下，应用程序层和表现层一一对应，因为不同的表现层可能会有不同的用例。
应用程序层引用领域层和基础设施层，对业务逻辑一无所知，不包含任何与业务相关的状态信息，应用程序层有时候需要调用外部服务，比如WCF或者WebApi，又或者是第三方的服务，这种情况一般是把对外部服务的调用封装成适配器，放在基础设置层，这样就把对外部服务的调用转化成了对基础设施层的调用。
正常来说，应用程应该是很薄的一层，不应当有业务规则或逻辑，主要面向用例和流程相关的操作。但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。
领域层
领域层包含了几乎所有的业务逻辑，由一组领域模型和一组服务构成。其作用是实现系统核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
领域模型：包含数据和行为，与之相对的一个是贫血模型，什么是贫血模型，如果只是类缺少方法，对象模型并不算是贫血，如果实体的逻辑放在了实体类的外面，那才是真的贫血，毕竟如果把逻辑放到了实体类的外面，他实际上是违反了SOLID原则。
领域服务：它包含了一些逻辑上有关系并且操作多个实体的行为。
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。实体和领域对象在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，就需要适用到领域服务，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
基础设施层
基础设施层是与具体技术有关的东西，比如数据库，网关，安全，日志，IOC，跟踪，缓存，服务总线等等。
基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务。比较常见的功能还是提供数据库持久化。
