2007年Eric Evans发表《领域驱动设计》至今，领域驱动设计（DDD: Domain-Driven Design）的概念愈来愈被人了解与使用。我已经算是一个后知后觉者，但亡羊补牢，为时未晚。我们对领域这个词非常熟悉，而且经常放在嘴边，但又有多少重视它？开发人员更关注于技术，事实上我也是因为想要研究基于DDD的ASP.NET开发框架ABP（ASP.NET Boilerplate）。ABP是个开源框架，其分层框架，其代码逻辑有许多值得学习的地方，但如果要真正掌握它，我认为还是先从理论上理解，从思想上做些改变，所谓磨刀不误砍柴工就是这个道理。
领域驱动设计（DDD: Domain-Driven Design）的核心在于领域模型，首先是要通过足够的沟通交流建立起一个领域模型，然后由领域模型驱动软件设计，用代码讲这些概念设计成一个领域模型。如何沟通交流？需要一种领域专家、软件设计人员、开发人员都能够理解的通用语言，曾经UML似乎就是希望作为一种建模语言，达成从分析到设计到编码的平滑过渡，但实际上UML在分析与设计上依然存在鸿沟，而且有很强的专业性。
领域模型很重要和必要，那么领域模型有什么特点？
领域模型是对某个领域的抽象，这个领域模型是有边界的，模型反应领域内我们关注的部分。这很好理解，任何一个系统的需求都有其边界，项目管理的范围管理也是在管理一个项目的边界，这会使得工作变得可控。
领域模型并不是要尽可能符合“现实”的模型。即使对真实世界如何的建模，那也是一种模拟。建立领域模型是出于某种目的而概括的反应现实，类似于电影，用一种特殊的方法展现给观众，讲一个故事，阐述一个观点。
领域模型只反映业务，与技术实现无关。比如人力资源领域、供应链领域与开发技术实现无关，但也有开发技术密切相关的领域，比如源代码管控系统，软件集成开发环境等。关于需求与设计的区别，一直有两种说法，直白的一种说法是：需求是关于要做什么，设计是关于要怎么做；另一种说法是：需求是关注业务领域，设计是关注技术实现。从这个角度看，领域模型是用于需求分析，或者确切的说是需求分析的工作产品。
领域模型是浓缩的知识，确保软件的业务逻辑在一个模型中，方便业务的理解。领域模型能够帮助开发人员平滑的将领域知识在转化为软件实现。事实上，开发人员绝大多数时候对业务领域并不熟悉，甚至可能完全不懂，这需要在开发前对开发人员做必要的业务培训。领域模型经过了提炼，可以更有效率的做到沟通。关键还在于围绕着领域模型，我们可以实现组件化，提高复用，也促使软件有更好的维护性。
领域模型贯穿软件需求分析、设计、开发的整个过程，成为一个团队所有成员交流沟通的核心纽带，大家面对的是同一个模型。旧的观念认为需求人员开发需求规格，设计人员研究需求规格编写设计书，开发人员依据设计书编写代码。领域驱动设计显然不认可这种做法，开发人员不仅要能理解领域模型，还需要为领域模型的细化和完善做出贡献。这也意味着领域模型贯穿软件开发的整个生命周期，不断的更新。
领域模型作为沟通的工具是可见的，需要表达出来。这种表达最常用的是图，也可是代码或文字描述。对这一点我是很好奇的，图很容易理解，比如用例图、流程图，代码怎么表达模型而让领域专家能够看懂？DDD建立一种名叫UBIQUITOUS LANGUAGE的领域通用语言或者说是模式。