DDD作为一种指导思想,还是有一些相对来说可以落地的东西,比如说他这个分层架构,整体分为以下四层:

在这里插入图片描述
实际上基于上图,我们可以把我们项目工程文件再具体一点,填写到上面的图片上
在这里插入图片描述

用户接口层(user interface):用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是:用户、程序、自动化测试和批处理脚本等等(其实我认为就是我们向外提供服务的那一层。)

应用层(Application):看资料一把来说这里不会有业务逻辑,一般是微服务的通道和多个领域或者服务的聚合。

根据 DDD 的原则,应用层要尽量简单,不包含任何业务规则或者知识,而只为下一层中的领域对象协调任务,分配工作,使它们互相协作,这一点在代码上表现为 Application 层中一般不会存在任何的条件判断语句。在许多项目中,Application 层都会被选为包裹事务(代码进入此层事务开始,退出此层事务提交或者回滚)的载体。

领域层Domain:领域层是业务逻辑核心,领域层主要体现领域模型的业务能力,它用来表达业务概念、业务状态和业务规则。
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

负责实现业务逻辑,即表达业务概念,处理业务状态信息以及业务规则这些行为,此层是整个项目的重点。

基础层infrastructure:就是我们一些基本设施,跟业务无关,数据库,中间件,网关,文件系统这些第三方工具。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐