如何运用DDD领域驱动设计巧妙应对业务需求变化，避免愚蠢应对策略？

本文共计5681个文字，预计阅读时间需要23分钟。

在封面+阅读目录：+具体业务场景+业务需求变化+愚昧的应对+消息列表实现+消息详情页实现+消息发送、回复、销毁等实现+回到原点的思考+业务需求变化，领域模型变化了么？

写在前面

阅读目录：

• 具体业务场景

• 业务需求变化

• “愚蠢”的应对

  1. 消息列表实现

  2. 消息详情页实现

  3. 消息发送、回复、销毁等实现

• 回到原点的一些思考

  1. 业务需求变化，领域模型变化了吗？

  2. 对象读取的额外思考

• 写在最后

领域驱动设计的核心－Domain Model（领域模型），这个大家都知道，可是，上次关于领域模型的设计分享，要追溯到两个月之前了，这中间搞了一些有的没有的东西，比如纠结于仓储等，说这些东西不重要，其实也蛮重要的，因为它是一个完整应用程序所必须要考虑的东西（Demo 除外），但是相对于领域模型，在领域驱动设计中它才是最重要的。

这篇博文我分享的思路是：一个具体的业务场景，一个现实项目的业务需求变化，应用领域驱动设计，看我是如何应对的？？？

注意：上面我用的是问号，所以，必不可少的会有一些“坑”，大家在读的过程中，要“小心”哦。

具体业务场景

具体业务场景？没错，就是我们熟悉的自由互联站内短消息，详见：[网站公告]8月17日14:00-15:00（周日下午）发布新版站内短消息。