对我而言，认识BLL层的作用，或者领域模型驱动的含义，最大的干扰来自数据库。
我们很清楚的知道UI层的含义，也知道数据层是做什么的。但对于一个简单的（甚至是相当复杂的）系统而言，实在不知道除了对数据库进行增删改查以外，还能做些什么？发布一篇博客，不就是在数据库里插入一条记录么？点击一下推荐，不就是在数据库里做一个update么？
为了避免数据库的干扰，这里，我们设定：不使用关系数据库做存储！请大家牢记，为了更清晰，更深刻的认识到这一点，我们再次明确，我们将使用最流行的NoSQL技术。牛叉吧！兴奋吧？
打满了鸡血吧！
好的，设计的任务交给你了，小李同学。
接下来，你怎么办？哎呀，我对NoSQL还不熟呀（不熟？其实除了名字知道以外，其他什么都根本就不知道）。马上开始研究一下NoSQL，看看里面有没有什么库呀，表呀之类的，好像那里面用的是集合？
如果你这样走下去的话，就偏离了DDD的宗旨了（但也不能说你“错”了）。
我是这样做的。
问：这个系统要做什么？有哪些功能？
答：发布博客，博客可以评论。可以提问题，回答问题。当然，做这些事，都得注册登录……
好，根据以上信息，我们可以抽象出这几个对象。
这是一个良好的开端。再细致点，博客和问题，都必须有标题；而博客的评论和问题的答案，不需要标题；但不管是博客还是问题，评论还是回答，都会有一个作者，都要发布时都要记录下
发布的时间，甚至发布者的IP（基于中国人都知道的原因）。博客和问题，还要记录下浏览量……
到这里，你是不是嗅到了一种什么味道？“不管……还是……都……”，共同的东西！那么想到面向对象的三大特征，“继承”就呼之欲出了。所以我们通过抽象，得到了以下的对象。
这样做的好处，很明显的，就是减少了重复代码。“代码越少越好”，我深以为然。当然，随之而来，还有其他好处，容后再表，呵呵。这里只说一句，良好的抽象是实现设计模式的基础。
其实，只要有面向对象的思想，进行这样的抽象是相当容易的（这样的抽象也是不对的，以后再论述）。但我们常常会被关系型数据库所干扰（尤其是有一定开发经验的程序员），而不敢进行这种“大胆的”抽象。因为即使将代码写到这里了，也得面临一个很现实的问题，接下来怎么办？最终我们怎么把这些对象持久化（保存到数据库或其他媒介中去）。这就是我们接下来要进行的工作了。
最后，对那些还想着数据库的同学，再重复强调一点：这个项目，我们用NoSQL！哦，sorry，改主意了，大家反映NoSQL太难了，又说干脆用xml文件吧。
随时随地看视频
