在项目中,我们一般都是分层,大家最熟悉的就是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中的业务类不是和表一一对应的,而且最主要的特点就是:每个业务类包含了很多的业务验证,状态跟踪等。职责很单一,便于维护和理解。
领取专属 10元无门槛券
私享最新 技术干货