子衿2023-01-29 来自上海老师这个地方有一个问题，我们通常为了方便微服务调用，会让Controller实现一个XxxApi接口，然后将XxxApi单独打包，这样下游可以将这XxxApi这个接口，通过maven引入到自己项目，然后直接通过XxxApi就可以完成远程调用，我们通常叫XxxApi所在的包为二方库，但如果将DTO放到了应用层，那么DTO和XxxApi就不在一层了，也就是XxxApi在适配器层，而DTO在应用层，如果强行将DTO也对外发布出去，会导致相关应用服务也被发布，这个应用服务对下游来说是没用的，这种有什么好的实践方式吗作者回复: 你们用的是RPC方式是吧。可以把DTO作为单独一个包，让API接口和应用服务都依赖这个DTO包，这样就不违反层间依赖了。
共 3 条评论8
Geek_1cb6f42022-12-29 来自广东这里有个疑问，开发中发现dto的属性命名实际是要与外部调用者的命名一致的，比如页面请求或者第三方接口。于是就存在同一个dto的多个版本。那么dto不就应该属于适配器层么？搬至应用层后就感觉不那么合适了。作者回复: 可以在应用层保存一个一致的dto,在适配器有另外多个不同版本的dto作为适配
共 4 条评论6
Jxin2023-01-09 来自湖北内容： 1.权衡问题，个人认为dto不该移动到应用层。就像要不要追加get set方法，原则上破坏封装性不要，实际上框架依赖只能要。java的rpc框架需要dto。如果你为交付负责，我觉得保守点，先追求框架红利，因为你算不准个中成本差异。 2.仓储的入参具象了（干没了加一层带来的扩展性），直接用聚合根实体就好。仓储是聚合的仓储。 课后题： 1.封装多态继承。可以，早期带团队面向对象落地难，用dci的思路带团队干过，效果能做出来，就是多了挺多概念，后期不好沟通。 2.add那块应用层里面。 说不上合不合理。核心逻辑是检验，检验我的观点是跟着领域对象走。但你说dto或则其他内部类加点检验可不可以，可以，不放内里面行不行，挺好，我就只抓领域层内部，其他的不放类里面指不定还是好事。（富客户端 api传递依赖 都是麻烦）（对象转换可以用框架，干净些）作者回复: 两个问题回答都不错。 关于DTO是否一定要放到应用层的问题，是不一定的。DDD最强调的是领域层要整明白，其他层都好商量。Eric Evans在自己的github例子里就是把DTO放在展现层的。不过还是不建议违反层间依赖原则。这个课程里把DTO放到应用层，是更强调六边形架构的思路。
共 3 条评论3
gitqh2022-12-31 来自广东关于将dto移动到application层解决外层依赖内层的问题，我在项目中会用另外一种方式，dto依然在adapter层，adapter层在调用application层的方法时，将参数转换为domain层的对象，这种方式也没有破坏外层依赖内层的规则。 关于这两种方式的对比，想听听老师的观点作者回复: 这样也可以，其实Evans本人写的代码例子就是这么做的（在Github上搜 dddsample)。我们的课程里之所以这么做，是参考了六边形架构，在六边形架构中，适配器主要适配输入输出的技术关注点，而DTO和领域对象的转换已经不是这个意义上的技术关注点了。所以如果追求纯粹一点的六边形架构，那么就按课程里的，否则，你们现在的做法也可以。
共 2 条评论2
磐石2022-12-30 来自广东看高潮了，爽文，继续更新，不要停作者回复: 继续努力
共 2 条评论2
一步2022-12-28 来自广东依赖倒置那个 有2个问题需要请教下老师： 1. 适配器层中 仓库的实现类，什么时候注入 到 Service 中，这里肯定不能在 Service 中初始化 否则还是会依赖 2. 适配层依赖 领域层，这里不是跨层依赖了吗？作者回复: 1，用@repository @autowired spring自动会注入 2，分层架构一般只规定方向对就可以了，没说不能跨层
2
NoSuchMethodError2023-04-23 来自江苏有个问题想问下，我看到有说法说app层只负责业务流程的编排，那业务流程是不是指的是业务用例或者系统用例？作者回复: 如果关注的是整个企业的人和系统的交互，就是业务用例；如果关注的是人和单个系统的交互，就是系统用例。和app层直接相关的是系统用例。不过“app层只负责业务流程的编排”这句话本身过于笼统，含义不明。准确的说，app向外部提供的一个API对应与用例中的一个步骤。
1
Ramanujan2023-03-15 来自广东老师，你这个实现是贫血还是充血作者回复: 简单回答：偏面向过程（我用“面向过程”代替“贫血”的说法）。详细回答：在领域对象不直接或间接访问数据库的情况下，尽量面向对象（我用“面向对象”代替“贫血”的说法），在纯粹的面向对象和纯粹面向过程之间取得一个平衡。
1
请叫我和尚
2023-01-05 来自广东一些思考和问题 1. 如何保证模型永远是最新的，有时候只会改代码，不改模型，这里就是绝大部分程序员不能保证统一，很多时候文档迭代就会滞后。 2. 领域逻辑体现在应用层的OrgService里行为validate、buildOrgDto、buildOrg位置不对，应该把这些行为放到各自的领域对象里，比如validate、buildOrgDto放到OrgDto里，buildOrg放到Org里作者回复: 1 首先让模型轻量一点，其次要完善开发流程，在需求梳理，代码评审等环节检查 2 这些确实没放对，下节课聊
共 2 条评论1
Faddei2023-08-30 来自浙江老师请教下，repository 查出来的对象就是 domain对象了吗？还是需要再封装一个DO类，再将DO转换成domain作者回复: repository 查出来的就是领域对象了，不需要再封装。某些情况下要用DO的话，也是 repository 内部的实现，外面是看不到的。