最近一段时间，学习了传说中的领域驱动设计。简称 DDD，Domain Driven Design。简单来讲，其核心概念就是在工程实现的过程中引入现实模型，而且最好能够将其他学科里的概念直接用计算机工程里的概念表示出来。
举例来讲，实现一大针对某行业的专业的大型程序至少需要两方面的人才。一类是该领域的专家，他们熟悉自己的专业。另一类是计算机工程师，他们能够写出计算机程序。在计算机工程中，我们有面向对象编程的概念，习惯用类的概念来表达现实生活中的概念。本质来讲，领域驱动设计就是将这种方法扩大化，在整个系统的层面上完成领域问题和计算机问题的映射。具体实现时，是很有难度的。首先，不是所有的现实领域中的问题和概念都能被计算机系统中的概念来表达。尽管我们有面向对象，有继承，多态等等手段，很多问题还是不能够被完全地表示。其次，构造一个能够深刻反应领域模型的计算机系统，意味着领域专家与计算机工程师需要有极其深度地沟通与磨合，彼此都要对对方的领域有一定的了解，这在实际工作中是比较难实现的。
《领域驱动设计——软件核心复杂性应对之道》这本书对 DDD 的实践提供了很多真知灼见。其中，有一部分我已经在工作中体会到了或者理解了，同时，也有很大一部分我一知半解。本书很少涉及具体代码的写法，更多是工作流程的指导和构架大型系统的思路。
深入地学习领域知识
当使用计算机技术为复杂领域编程时，首先应该掌握领域中的核心知识。随着了解的深入，团队中的代码的命名和结构需要直接反映出领域知识。并且，当团队成员相互沟通时，也应该提炼出一套基于领域知识的专业术语。
领域模型是软件系统的核心部分
如果只把软件系统看作是数据的存储与计算，所有的软件系统都是一样的。一个专业的软件系统最核心的部分体现在对现实领域问题的翻译，即领域模型的计算机系统中的表达。一个大型的软件系统需要分层，比如可能包括，用户界面层，应用层，领域层和基础设施层等等。其中，领域层是反应核心业务的关键。在具体的工程实践中，很多工程人员不喜欢做业务代码，认为其没有技术含量，实际上，正是业务代码才是整个团队的核心，需要安排最好的工程师。
有很多工程方法可以帮助引入领域设计编程
包括
Specification
Intention revealing interface
Assertion
Conceptual contour
Model driven design
Strategy
Composite
Bounded context
Continuous integration
Context map
Shared kernel
Customer/Supplier development team
Conformist
Anti-corruption layer
Separate way
Open host service
Published language
Core domain
Generic domain
Domain vision statement
Highlighted core
Cohesive mechanism
Segregated core
Abstract core
Evolving order
System metaphor
Responsibility layer
Knowledge level
Pluggable component framework
