04｜跨越现实的障碍（上）：要性能还是要模型？

感谢老师的好文章。我这边有个疑问，专栏聚合了内容同理也可以用关联对象模式，那如果作者需要对专栏里的其中一个内容进行修改，需要先获取专栏然后通过关联对象获取要修改的内容进行修改，再将整个专栏聚合进行保存，这样是否还是没有保障到性能呢？

想请问为什么不直接在UserRepository中添加关于分页的逻辑？虽然能感觉到不太恰当，但是好像也没暴露逻辑，并且user也没依赖具体db实现

以前只是觉得语言中对象与关系型数据库之间的转换非常不自然，从未问过为什么会是这样，感谢老师今天帮我理清这层关系，原来二者在单体架构时期是等价，是因为后来分层以后才被割裂了，感觉现在的多层是把以前在语言内部实现的机制给放大化了，且为了通用性把CRUD等细节暴露出来了，导致编程语言在使用时感觉不那么自然和一体化了。 通过将隐式的概念显式化建模，就我自己的理解是需要把隐藏背后想表达的真实意途给找出来，比如今天的例子就是要操作数据，操作数据可以是操作数据库也可以是操作NOSQL等其它各种实现方式，第一反应是操作数据库是一种惯性思维，它并不是真正想要做的事。

关联对象我更多的是用来解决业务上的多对多关系，至于分页这个逻辑，我倒是目前还没遇到过这样的场景，不过看完有一些疑问：Subscription虽然通过接口隔离了数据库操作，但是如果Subscription本身有一些业务逻辑呢？是否就考虑把接口换成抽象类，在抽象类中实现业务？ 另外，在我看来，这种方式应该只在遇到数据库性能问题的时候使用，不应该作为通用方法来使用。有一些影响领域模型只对业务模型进行实现的单一职责。 另另另另外，CQRS邪教您如何解读的？

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

集合是面向对象模型中广泛存在的概念,如果全都使用关联对象进行建模, 是否会导致类爆炸呢? 有什么可以遵循的规则或者方法来鉴别哪些隐式的集合概念使用关联对象进行建模比较好, 哪些则不然呢? 是不是如果两个对象之间仅仅是简单的包含关系, 可以先用系统提供的集合容器来建模实现, 等到业务复杂了, 需要对这个集合进行除了增删改查之外的操作时, 再使用关联对象进行建模?

老师有没有好的项目和代码，推荐一下。结合着研究下

关联对象确实是一种很巧妙的方法。但是也有疑惑，比如UserRepo获取user后，修改其部分subscriptions，容易产生修改逻辑后UserRepo.set(user)。而其实应该是在Subscriptions关联对象上操作。关联对象隐藏了Subscription聚合的Repo。 而Eric的DDD中，则是大聚合拆分出多个小聚合，然后通过小聚合中持有聚合根的Id相互关联。同时小聚合自然有自己的repo。而这种拆分，模型的完整性和独立性也减弱，所以需要结合service来完成业务。 既然引入关联对象，完全去Repo如何？UsersRepo直接用Users来替代。

“集合作为面向对象中的重要概念，被吸纳入这些语言后，就去掉了与数据库的强关联”——从语言演进历史得出问题本源，膜拜！

看到作者thoughtWorks背景毫不犹豫就订阅了，看到这里就感觉值回票价了