关于内容： 1.基础类型偏执。这是一个坏味道，但仅在个人或者小团队的小项目中能看到它被认真对待（也只有刻意训练，践行代码健身操时能被认真对待）。一旦项目变大时间变长人数变多，不知不觉就被抛弃了（毕竟这么写对于不理解的人来说真的会被骂死。一段代码要求阅读者有比较高的认知才能有比较好的可读性。以教育阅读者为前题的同理心写出来的代码还算得上同理心吗？）。 2.CQRS。就这个分页场景，我多半是以单独的查询模型来承接。只有在命令/写操作才会构建聚合来实现。这么想来，似乎破坏了一个聚合模型应有的完整性。停顿几秒钟，这里我本觉得只是遵循CQRS，但实际上只是单纯不希望领域聚合实体具备任何io操作。确实，这样没有依赖任何除jdk程序库之外的技术代码，但是pojo对象的行为运行期具备db操作，而这自然又会牵扯到框架，那么这个pojo对象便不再纯粹，只能算是伪pojo。概念的咬文嚼字没有意义，不过伪pojo多了io操作这个不可靠因素，测试验证自然也得多些操作和心思，这是好是坏呢，从长期看又如何？。合理了模型的概念却提高了迭代维护时的心智负担，这是个问题。毕竟我们学习概念，并非想捧着去吵架，而是想通过概念解决自己的实际问题。 课后题： 1.隐式概念：规则，流程，参数（一个函数入参太多时，往往会引起我们的关注和思考，看看这里是不是有一个隐式的概念能包含这些参数） 2.发现有滞后性，基本只有在迭代中，坏味道积累到一定程度，引发注意，重新定义和审视时才能发现。但更多的时候是被遗漏。不过漏了本身感觉也并非不合理，不见得就是麻烦。