单独阅读《领域驱动设计》这本书比较吃力，但结合钟老师的专栏一起读，就轻松了很多，最起码看的懂 UML 图了，对理解内容有了很大帮助。 我确实没有「面向对象方法学的基础」，通过专栏才知道：面向对象针对数据全部能装入内存中的程序比较友好，存取方便；但工作中数据基本都是存数据库的，一直写的是过程式代码。 非常赞同「模型的重构」这个观点，正如《领域驱动设计》序言中所说：「Eric 的经验告诉我们，真正强大的领域模型是随着时间演进的，即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法」。 《分析模式》这本书买了，是钟老师翻译的这个版本，还没拆封。原本以为读完《领域驱动设计》就能读懂了，现在看来至少要先读完「面向对象」的两本书后再来挑战。 看了钟老师分享的书单后很激动，在新的一年里跟着书单学习 DDD，走向星辰大海。 最后分享一段令我对「创建复杂对象」豁然开朗的一个例子（摘自《领域驱动设计——软件核心复杂性应对之道》 6.2 模式：FACTORY）： 如果再让复杂对象负责自身的创建，那么职责过载将会导致问题。 汽车发动机是一种复杂的机械装置，它由数十个零件共同协作来履行发动机的职责﹣﹣使轴转动。 我们可以试着设计一种发动机组，让它自己抓取一组活塞并塞到汽缸中，火花塞也可以自己找到插孔并把自己拧进去。 但这样组装的复杂机器可能没有我们常见的发动机那样可靠或高效。 相反，我们用其他东西来装配发动机。或许是机械师，或者是工业机器人。无论是机器人还是人，实际上都比二者要装配的发动机复杂。 装配零件的工作与使轴旋转的工作完全无关。只是在生产汽车时才需要装配工，我们驾驶时并不需要机器人或机械师。 由于汽车的装配和驾驶永远不会同时发生，因此将这两种功能合并到同一个机制中是毫无价值的。 同理，装配复杂的复合对象的工作也最好与对象要执行的工作分开。