几乎每种语言、开发框架和工具面世时，都号称要把开发人员解放出来，让他/她们更加关注于业 务逻辑的处理。但目前的工作状况是，每当一个新的“解放工具”出现，就会有众多的技术狂热者蜂拥而上，而忽略了他们最应该关注的业务逻辑部分。还好，从 2004年开始，“领域驱动设计”的声音开始浮现，开始逐渐扭转这种局面。

领域驱动设计词解

尽管提出人Eric Evens 已给出了领域驱动设计的官方的解释，但始终让人感觉存在一些困惑。笔者将从一个工程实践者的角度来重新对这些词

随着OOA&D的流行，人们普遍认同一开始建模的时候不应考虑实现细节，而应把注意力集中在对领域的深刻理解上。领域模型里的对象结构与实际的数据库表结构可以有很大的不同；实体间的关联也不一定非得实现为外键关联……不过请不要把可以忽略实现细节等同于可以忽略细节领域知识。正所谓“细节就是魔鬼”，醉心于抽象和一致性，而没有把同等甚至更多的精力投入到发现不一致的细微之处上，实在是一种很危险的做法。所谓“具而不抽则罔，抽而不具则殆”，让思维在抽象和具体之间来回移动才更有效。示例场景还给了你

源贴:http://www.javaeye.com/topic/281289?page=1

很久以前大家就关于这个方面有很多讨论了。前两天我又挖了一个坑来集思广益，非常感谢没 有把我的帖子投为新手帖的同志。我不是在装傻，只是想让大家跳出自己的立场，从根本的价值出发来考虑问题。之前有很多讨论，都是在讨论我又发明了一种新方 法可以让领域模型充血啦，等等之类的。当提出一个解决方案的时候，一定要有明确的问题。那么领域模型的价值是什么？为什么没有被广泛应用，其困境在哪里？