前言：之前的文章，很多朋友发来了反馈，从反馈中也看出了一些问题，一个最明显的问题就是：当我提到DAL的实现的时候，一些朋友就问：DAL中采用了Repository模式吗？ 初一看起来，可能认为这个问题没有什么，其实仔细的想想就会发现，确实在问题的背后隐藏的了另外的一个问题。
本篇的议题如下
1.问题的阐述
2.设计方法
3.总结
1.问题的阐述
在项目中，我们一般都是分层，大家最熟悉的就是UI，BLL，DAL层，或者在加上一个Services服务层。一般的项目就这样设计了。由于越来越多的公司，社区倡导领域驱动设计（DDD），于是，又有了项目的分层的方式，DDD设计中的一些概念也引入了： Presentation， Service， Domain， Repository. 而且一般来说，有下面的对应关系：
Presentation UI
Domain BLL
Repository DAL
但是在开发的时候，一会儿在项目中建立一个Domain的类库，一会儿又在项目建立DAL，最后的情况就是：UI， Domain， DAL等等。 其实这倒是没有什么，说到底只是一个名称的问题，但是在只后面隐藏的问题就是：对DDD的不了解，很多的时候只是注重了”形”，而没有领会到”神”。
在项目中不是建立了名称为Presentation， Domain， Repository的类库，这个项目就是DDD开发了，不是这样的。本来在分层的时候采用UI，BLL，DAL，自己是很熟悉的，但是这样一搅和， 最后反而把概念搞复杂了。
而且，在项目中，是采用原来朴实的那种三层，还是采用DDD开发，是要经过思考的，不是那DDD的方法来套。也就是说，不要为了DDD而DDD.就像当初我们学习设计模式一样，没有必要在写代码的过程中为了设计模式而设计模式。
2.设计方法
到底是采用DDD还是那种朴实的三层，主要取决与业务层的设计和系统的复杂度。
如果系统确实很复杂，业务逻辑相当的复杂，那么建议采用DDD，因为DDD的引入就是用解决复杂性的。因为采用DDD的方法来设计业务逻辑层，那么业务逻辑层就只是关注业务逻辑的处理，至于怎么存储和获取数据，丝毫不关心，所以基于这个原因，在DDD中就引入了Repository的概念，Repository就是来辅助业务逻辑层处理数据的。
虽然我一直在提”朴实的三层”，其实DDD和它之间没有什么很明显的划分了，这里我之所以特意的把他们划分出来，主要就是因为我们在项目开发中一般是三层（或者N层），这里提出主要是为便于后面讲述一些问题。
下面就开始讲述一些业务逻辑层设计方法，相信大家看完之后，很多的疑惑就迎刃而解了。
业务层的设计方法有三种：Transaction Script， Active Record和Domain Model.
看过Flower的《《企业架构模式》》一书的朋友应该对上面的三个词语很熟悉，在书中，这些概念讲的确实很精炼，可能因为精炼，所以理解起来就不是很容易。
在本篇文章中，就涉及到了这些知识，只有把这些点讲清楚了，之前的问题就能解决。
如果熟悉这些概念的朋友，也不妨看看，大家可以交流！
首先来看看Transaction Script（之所以没有翻译为中文，因为翻译后的中文意思很容易让人产生误导）
其实Transaction Script就是过程化的设计方式，最直观表现就是一个个的方法，每个方法做一个业务的流程。我们来看下面一个例子。例子的背景就是在电子商务网站中订单的处理流程。
