领域驱动设计的核心－Domain Model（领域模型），这个大家都知道，可是，上次关于领域模型的设计分享，要追溯到两个月之前了，这中间搞了一些有的没有的东西，比如纠结于仓储等，说这些东西不重要，其实也蛮重要的，因为它是一个完整应用程序所必须要考虑的东西（Demo 除外），但是相对于领域模型，在领域驱动设计中它才是重要的。
　　这篇博文我分享的思路是：一个具体的业务场景，一个现实项目的业务需求变化，应用领域驱动设计，看我是如何应对的？？？
　　注意：上面我用的是问号，所以，必不可少的会有一些“坑”，大家在读的过程中，要“小心”哦。
　　具体业务场景
　　具体业务场景？没错，是我们熟悉的博客园站内短消息，详见：[网站公告]8月17日14:00-15:00（周日下午）发布新版站内短消息。
　　上面那次版本发布，已经过去一个多月的时间了，说是“新版”，其实是重写之前短消息的代码，然后用领域驱动设计的思想去实现，界面换了个“位置”，功能和原来的没有太大变化。发布之后，出现了很多的问题，比如前端界面、数据库优化、代码不规范等等。有些技术问题可以很快的解决，比如数据库的索引优化等，但是，有些问题，比如 SELECT FileName，因为程序代码是基于领域驱动设计的思想去实现的，那你不能直接去写select filename1，filename2，filename2... from tablename这样的 SQL 代码，所以实现起来需要思考很多，这个是比较头疼的。
　　我为什么会说这些问题？因为这些问题，只有在实际应用项目中才会出现，你搞一个领域驱动设计的简单 Demo，会出现数据库性能问题吗？肯定不会，那也不会去思考仓储的一些问题，更谈不上一些改变了，所以领域驱动设计的推进，只有你去实际用它，而不只是做一些演示的东西，在实际应用中，去发现问题并解决问题，我觉得这样才会更有价值。
　　关于短消息这个业务场景，其实我之前写的一些领域驱动设计博文，都是围绕着它展开的，很多园友认为这个业务场景是我虚构的，像之前 netfocus 兄问我：“你说的这个短消息是不是类似于博客园的短消息？”，我回答：“是的！”，呵呵。后来我发现虚构的业务场景，有时候很难说明问题，比如之前 Jesse Liu 在一篇博文中，提到一个用户注册问题，关于这个问题，其实讨论了很久，但后结果呢？我认为是没有结果，因为业务场景是虚构的，所以会造成“公说公有理，婆说婆有理”的情况，以至于大家很难达成一些共识的点。
　　博客园短消息的业务场景，真实的不能再真实了，毕竟大家都在实际用，我不多说了，是简单的一个用户和另一个用户发消息，然后进行回复什么的，在之前的一些博文中也有说明，大家可以参考下：我的“第一次”，这样没了：DDD（领域驱动设计）理论结合实践。
　　业务需求变化
　　现在的博客园短消息，为了方便用户看到之前回复的一些内容，我们在底部增加了“=== 下面是回复信息 === ”，示意图：

　　这种方式其实是把之前回复内容放到新消息内容里面，然后作为一个新消息进行发送，除去消息内容“冗余”不说，还有个弊端是，如果两个人回复的次数很多，你会发现，消息内容会变成“一坨XX”，不忍直视。
　　后来，我们也看不下去了，所以决定做一些改变，仿照 iMessage 或 QQ 那种消息模式，示意图：

　　这种方式和上面那“一坨XX”形成了鲜明对比，对话模式的消息显示，使用户体验度更好，像两个人面对面说话一样，很轻松也很简洁，我想我们这种方式的改变，会让你“爱上”我们短消息的。
　　对，没错，这是业务需求变化，我们在应用程序开发的过程中，需求是一直不断变化的，我们要做的是不断完善和适应这种需求变化，当然每个人应对的方式不同，下面看一下我“愚蠢”的应对。