要性能还是要模型？

极客时间《如何落地业务建模》学习笔记 05

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

如果只看题目，那么我觉的在开发的初期，为了增加对业务的理解，可能会更更看重模型，而到了实施或者运维的阶段，也许会更多的考虑性能。

当然，其实大部分的时候，性能和模型并不是对立的，只是需要“平衡”。

文中关于 Smalltalk 和面向对象历史渊源介绍确实能够帮助理解多层架构中遇到的结合与数据库的割裂，这种割裂，归根到底是不是源于需要处理的数据量越来越大，以至于无法和编程语言绑定在一起。

现在的架构可能已经超越了“多层”的境界，进入了所谓“云架构”的时代，那么又会带来什么新的挑战么？

在代码的帮助下，不难理解关联对象，我有一种错觉，以前也会写“关联对象”，但当时的关联对象大部分是贫血模型，而本篇中的关联对象似乎是充血模型？

使用自定义关联对象，而不是集合类型来表示对象间的关联

MySubscriptions 和 MyReaders 这两个名字起得有点不讲究，可能还不如 Subscriptions 和 Readers，User.Subscriptions 和 Column.Readers 看上去还挺清爽的。

分层结构通过引入一个新的抽象层来解决问题，面向对象通过引入另一个对象解决问题，那么，领域驱动设计可能会引入一个新的领域或者上下文来解决问题？

对于领域驱动设计中的隐式概念，我没有什么想法，主要是在之前的工作中并没有真正落地领域驱动设计。