领域驱动设计

在项目中,我们一般都是分层,大家最熟悉的就是UI,BLL,DAL层,或者在加上一个Services服务层.一般的项目就这样设计了.由于越来越多的公司,社区倡导领域驱动设计(DDD),于是,又有了项目的分层的方式,DDD设计中的一些概念也引入了: Presentation, Service, Domain, Repository. DDD是一套综合软件系统分析和设计的面向对象建模方法，而且一般来说,有下面的对应关系:

在项目中,是采用原来朴实的那种三层,还是采用DDD开发,是要经过思考的,不是那DDD的方法来套.也就是说,不要为了DDD而DDD.就像当初我们学习设计模式一样,没有必要在写代码的过程中为了设计模式而设计模式，而是依据项目的复杂程度还采用三层还是DDD

服务器后端发展三个阶段：

UI+DataBase的两层架构，这种面向数据库的架构没有灵活性。

UI+Service+DataBase的多层SOA架构，这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差，

DDD+SOA的事件驱动的CQRS读写分离架构，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。

对于业务逻辑相当的复杂的项目,那么建议采用DDD,因为DDD的引入就是用解决复杂性的.采用DDD的方法来设计业务逻辑层,那么业务逻辑层就只是关注业务逻辑的处理,至于怎么存储和获取数据,DDD中 的Repository层就是来辅助业务逻辑层处理数据的.

业务层的设计方法有三种:Transaction Script, Active Record和Domain Model.

Transaction Script就是过程化的设计方式，最直观表现就是一个个的方法，每个方法做一个业务的流程

针对Transation Script方式的设计，每个动作对应一个类方法，全部放在一个管理类中，比较直观。但是业务复杂起来，方法就会很多，需要进行重构，管理较为困难。

Active Record

业务实体类基本和数据库中表是一一对应的，每个业务类自己负责自己的数据存取，也就是说在业务类中包含了业务逻辑的处理和数据的存取

这个方式最大的弊端就是：数据库表只要改动，那么业务逻辑层动，而且这种变动会一直波及到了UI那端

Domain Model

业务层就只是关注把现实中的概念转换为相应的业务逻辑模型，在电子商务网站开发中，一些概念就被建模表示为一个个的业务模型(也就是业务类)，Order, Shopping Cart, Customer等。而且和Active Record最大的区别就是：Domain Model中的业务类不是和表一一对应的，而且最主要的特点就是：每个业务类包含了很多的业务验证，状态跟踪等。职责很单一，便于维护和理解。