架构那点事系列二 - 大话3D

       近几年，架构领域兴起了很多新型架构思想。DDD成为继OOD之后又一个被人津津乐道的设计风格。.这里结合自己工作实践，和大家分享一下自己的DDD实践观，首先向大家推荐一篇关于DDD的文章（http://msdn.microsoft.com/en-us/magazine/hh547108.aspx.看看微软的卓越工作，从DataTable到EntityObject. - Net 4.0来了，随之为我们带来了EntityFramework）。这里，我们抛开语言特性，从本质上分析一下DDD的诸多实践要点。

       首先，我们需要知道DDD和OOD有何不同？在此之前，我们先从模型上进行下对比。对象模型，我们都知道它封装了数据(属性)和行为(方法和事件)。而领域模型则是驻足在某领域内的对象模型。相应地，它的行为是用于表达业务规则和特定的业务逻辑。更重要的是，每个实体都可能处于某一状态，并且与一组动态的验证规则相绑定；领域模型表述的是领域中各个类及其之间的关系。类关系是多样的，比如组合、聚合、继承、实现等，而数据模型不是一对多，就是多对多。从领域驱动设计的角度看，数据库只不过是存储实体的一个外部机制，是属于技术层面的东西。数据模型主要用于描述领域模型对象的持久化方式，应该是先有领域模型，才有数据模型，领域模型需要通过某种映射而产生相应的数据模型(数据依赖于实体，是实体的状态，离开实体的数据是毫无意义)。

       ok，有了基本认识后，我们再来看一下领域驱动设计所倡导的分层。如图:

     

　    基础结构层：不解释了。注意，这部分不会涉及任何业务逻辑。传统的数据访问层，也被放在了该层当中，因为