可能出现的问题

Domain层代码非常少

xxxExe 避免 Service 膨胀利器

domain层是最核心的业务规则，他不依赖任何的层
可能重构的过程中会发现 domain的内容很少，别慌，我们目前大部分都是好几个表存来存去

感觉这是最大的问题：项目设计时优先设计的表结构，拿传统的方法用表结构倒推实体对象，把实体对象仅当成数据容器
开发流程是 Mapper > Enitiy > Service > controller
ddd要关注领域对象建模，可能先建领域对象再设计表会好点？

调用其他模块的domain层接口时功能与参数偏差严重

例：新建企业接口，需要同时创建默认部门，默认角色，管理员账号。默认的对象不可编辑删除
但部门，角色，账号模块只提供了普通的创建接口，不满足创建默认角色部门账号的要求

这个问题属于领域对象Entity没封装好。
如果领域对象是普通的pojo，那对其他领域提供接口时还得在逻辑里加校验，防止调用入参不合法
正确做法是：在领域对象内包含自检逻辑，确保入参合法

按ddd概念来说，跨领域对象的逻辑应该在 domainService。
但对接时发现其他人逻辑没全写在domain层里，在app层的executor 校验参数时也耦合了一部分业务逻辑。。。难受

工具类，枚举类等分散在Adapter层、app层、domain层。出现下层(domain)调用上层(app)代码的情况，最终决定统一迁移到domain层
总结、建议
优先领域对象建模，然后设计数据库对象
业务逻辑、公共类写在domain层
Entity 领域对象包含自检逻辑