企业级业务系统开发我们略过需求的采集、分析，直接进入设计。
领域驱动设计（DDD）是近10年流行、比较成熟、比较成功的软件设计方法、理论。我们早期常见的软件开发方式是拿到产品需求后，直接考虑数据库中表应该如何设计，这种方式已经将设计与业务需求脱节，而更多的是直接考虑应该如何实现了，这有点本末倒置。而DDD是从领域(问题域)为出发点进行的设计方法。
这里先说一下领域驱动设计的概念：是一种以领域为核心的设计方法与理念。建立正确的领域模型是领域驱动设计的核心。
我的理解：
DDD(领域驱动设计)是一种设计方法，它是通过捕获与分析产品需求的领域概念，然后将这些领域概念设计为领域模型，领域模型从本质上反映了产品需求。通过领域模型作为指导，最终作为软件代码的依据。DDD中包含了大量成熟的方法、模式和架构，DDD这种设计方法或理论比OOD等设计方法更靠近产品的需求，也更靠近编写的软件代码。这里需要重点说明的是：
1.产品需求！=用户需求：用户需求是用户站在自己角度描述的系统能够完成的功能，通常只能是需求分析师进行需求采集的产物，而产品需求是通过分析用户需求后形成的用户本质的需求，通常的表现形式是“需求规格说明书”或“四色原型模型”。另外领域模型应该关注的是领域核心的概念，而不应该过多的考虑将用户如何纳入领域模型中。
2.领域模型是对某个边界上下文的领域的表示，是反映了产品需求的本质。
3.领域模型应该包含领域的业务逻辑，这样可以提高业务的可理解、可维护、可重用。DDD一般建议领域模型为充血模型，也就是一个领域模型除了包含状态，还应该包含自身业务的行为，不应该是只包含POCO，而不包含行为的贫血模型。我个人认为不应该简单的认为应该建立贫血模型还是充血模型，而是模型应该是能够包含自身的状态，并且能够维护自身的业务规则。
4.领域模型只考虑业务，与技术无关。我认为与技术无关只是说明领域模型关注的重点是业务，而不是技术，但是在领域建模时，还是要考虑到技术方面的实现，比如性能等。
5.通用语言。在需求分析和设计的过程中，用户、领域专家、开发人员沟通应该采用一种通用语言。这里说的通用语言我认为主要表示两个含义，一是对领域中的一些概念应该明确，并使用这种明确的语义进行交流，二是最好在一个领域模型上进行需求与设计的讨论。但在中国好像第二种方式比较困难，一种原因是中国的用户不习惯，第二种原因是开发人员不希望用户直接看到模型。
6.有了DDD的一些模式、架构以及领域模型后，设计可以平滑的实现为软件代码。
7.在设计与实现的过程中，用户、领域专家、开发人员会不断交流，会对领域模型进行不断的细化、完善。另外需要注意的是，代码的实现必须要依赖于领域模型，如果有偏差，要么调整代码，要么是原来的领域模型不够完善，需要调整领域模型。
8.领域模型是整个软件的核心，是最有价值的部分。
欢迎加入QQ讨论群：309287205