DDD作为一种指导思想，还是有一些相对来说可以落地的东西，比如说他这个分层架构，整体分为以下四层：
实际上基于上图，我们可以把我们项目工程文件再具体一点，填写到上面的图片上
用户接口层（user interface）：用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等（其实我认为就是我们向外提供服务的那一层。）
应用层（Application）：看资料一把来说这里不会有业务逻辑，一般是微服务的通道和多个领域或者服务的聚合。
根据 DDD 的原则，应用层要尽量简单，不包含任何业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使它们互相协作，这一点在代码上表现为 Application 层中一般不会存在任何的条件判断语句。在许多项目中，Application 层都会被选为包裹事务（代码进入此层事务开始，退出此层事务提交或者回滚）的载体。
领域层Domain：领域层是业务逻辑核心，领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
负责实现业务逻辑，即表达业务概念，处理业务状态信息以及业务规则这些行为，此层是整个项目的重点。
基础层infrastructure：就是我们一些基本设施，跟业务无关，数据库，中间件，网关，文件系统这些第三方工具。
