【架构设计 领域驱动开发 一】三层VSDDD

简介: 【架构设计 领域驱动开发 一】三层VSDDD

本篇为架构设计系列的第一篇,希望通过本系列转变自己的软件设计思想。不再只是单纯代码的搬运工,而要有自己的设计想法。本篇也是领域驱动开发的第一篇。

之前第一次接触java的web编程开始,就被书里提前灌输了如下思想:jsp - action - service - serviceimpl - dao - daoimpl - 数据库。好像这就是一套标准一样,后来在教一个学弟写后端的时候,他问你这service也没干嘛啊,你这serviceimpl好像也没干嘛啊,对了,你这hibernate也没啥作用嘛,我直接用jdbc不就行了,然后被我一顿无情鄙视:小伙子,以后你接触大项目就知道了,要按部就班,这都是前人经验,遵守就行了。其实自己也觉得哪里不对劲,这就是所谓的知其然不知其所以然。对于层层调用早已习惯,因为逻辑简单,按部就班,总不会出错嘛,数据被代码一层层送到前端展示,再一层层被反馈给数据库。各层隔离,多好。其实往往是这样,你越不愿意提前动脑子,你以后费的精力就越多。

三层架构之殇

其实对于小型项目,或者简单逻辑,三层往往就够了,比如我之前做的一个参加比赛的作品,只是几句简单sql然后调用数据层层转到前端用echarts显示就非常的简单,对于大型项目来说,就比较麻烦了,如果你的数据表上了一定规模,那么任何一个数据库内容修改动作都会牵一发而动全身,你得修改对应实体,甚至业务逻辑,而如果一个项目经过几波接手流转,更加难以寻踪。以下部分内容提炼自该篇,如有需求,可以访问。

从三层架构迈向领域驱动设计 http://www.cnblogs.com/betterman/p/4408630.html

三层架构是什么

三层架构的结构

大家眼里通用的三层架构应该是这样的:

严格分层架构模式的特点是上层只能访问相邻的下层,其他层次间的调用都不允许。三层架构就是一种严格分层模式,它把职责划分为界面展示、业务逻辑、数据访问三层,还有一个业务实体,前面三层都要依赖它,所以它并不构成一个层。这里有个问题,严格分层架构只能上层访问相邻的下层所以我们时常会遇到这个问题,action想直接从dao拿数据,但非要经过service,或者现在做的.net开发,我必须通过provider来获取,虽然可以提升安全性和使组织架构更严密,但却写了很多重复的代码(空壳调用),这个得依据具体实现场景了。

三层架构的编程思想

三层架构的特点是一种面向过程的编程思想,特点如下:

  1. 业务实体类中基本上只有属性没有方法。 (深表认同,感觉没什么意义,单纯为满足orm)
  2. 业务逻辑层的类基本上只有方法没有属性。 (一系列接口的堆叠)
  3. 将数据表结构映射为业务实体类是一个惯用做法,以至于有人将其称之为“传统”。这样的好处是只需要理解一套模型,能够通过自动化工具从数据表直接生成业务实体,还能够自然而然的通过自动化机制存储与检索业务实体。但对于复杂点的业务,这样做就是绝大部分问题的根源。
  4. 当业务膨胀起来,需要划分模块的时候,我们有个常用的变形:提取一个服务层出来,用来组合模块间的交互,还为业务逻辑层提供了一个防腐层,可以把记录日志、验证权限、处理异常等职责分配给服务层

典型的结构:jsp — action –service —dao 再加个业务实体

上面介绍的就是我们常说的三层架构,由于采用了严格分层模式,用户界面层是绝对不能跨过业务逻辑层调用数据访问层的,同理服务层也是不能调用数据访问层。其实三层架构还有个更准确的名字—-分层贫血领域模型架构,这样就不管多少层都能概括了,但是这名字没有三层那么朗朗上口。前面名字中的领域模型指的是业务实体,贫血意思业务实体中没有或很少方法。

三层架构缺点

工作简单枯燥

从数据库搬到界面或从界面搬到数据库,长期重复枯燥的工作会让人感觉前途无亮

新增功能,需求变化

1,有些功能,它可能牵涉到了所有的数据表,做这样一个功能,首先要把所有关联到的数据表都找出来,理解清楚表与表之间的关系,比较痛苦的是别人写的代码你基本用不上,都要自己从头搞

2,不知道什么时候需求发生变更。

代码复用率低

不能复用那些久经考验的代码,导致重复代码慢慢积累,系统缺陷也比较多

反思三层架构

三层架构的最大问题在于:实际应用中人们喜欢把内存模型和数据库模型保持一致。三层架构的大部分问题都是从这里衍生出来的。

DDD的优势

三层架构到DDD的转变过程

初步动作

优化层次关系–>重构到面向对象设计–>使用DDD相关模式深入重构

上面讲到,三层是“分层贫血领域模型架构”,那么DDD则可称为“分层充血领域模型架构”。

三层到DDD的过程大体是这样的:

  • 首先推翻严格分层的理念,采用松散分层来重新定义服务层(松散分层的意思是上层可以访问下层,而不只是相邻的下层),把调用数据访问层的职责交给服务层,接着把业务逻辑层移动到与业务实体在一起
  • 再接着融合业务逻辑与业务实体,使之成为面向对象的设计,然后利用DDD的模式进行更深入的重构。在DDD技术掌握的还不是那么扎实的时候,三层技术基本仍然能够继续使用。

我们看到业务逻辑与数据访问层已经没有依赖关系了。

由于目前的服务层职责是非常轻的,甚至有很多空壳的调用,所以平衡一下职责,把调用数据访问层的职责从业务逻辑层提升到服务层,需要的数据通过参数传递给业务逻辑层。这样,对于那些简单到无业务逻辑的CRUD就不需要去访问业务层了,直接调用数据访问层。

注意:有些逻辑无法归类到任何一个业务实体上的,就让它留在原地,成为一个领域服务。有些逻辑连领域服务都无法归类的,就让它留在服务层,在坚持大方向的前提下,细节灵活处理,因为每次重构都能够让你对未来的路看到更清楚,很可能下一次重构后你就会为这些流浪逻辑找到合适的家了。

这就是简单模型:基础设施依赖领域层

深化动作

标准分层结构

正式介绍一下DDD的分层架构,当然DDD的架构并不限于分层,现在还有六边形架构、CQRS、EventSourcing等技术可以选用,但是不要好高骛远,先把分层架构掌握好。我准备从标准的结构入手。

各层职责

用户界面层:

原版—-负责向用户展现信息以及解释用户命令。

补充—- MVC中V和C都属于UI层,V展现信息,C解析用户命令。UI像地图一样把各个控制器关联了起来。

应用层:

原版—-很薄的一层,用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态,但它保有应用任务的进度状态。

补充—-协调应用的活动这句话太抽象了,我充实一下它:从数据访问中获取领域对象,调用领域对象的方法完成任务,然后再调用数据访问代码把领域对象的改变持久化。事务、权限检查、记录日志、处理异常的职责也归它管。这点和前面三层的服务层的职责其实是一样的。

领域层:

原版—-本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给了基础设施层。

补充—-业务对象的持久化工作我们已经提升到应用层了,一般情况下,这层最好不要涉及资源库的调用,但是并不绝对。资源库的抽象要么在领域层中,要么提升到了“应用程序框架”,领域层是不会依赖基础设施的。

基础设施层:

原版—-本层作为其他层的支撑库存在。它提供了层间的通信实现对业务对象的持久化,包含对用户界面层的支撑库等作用。

补充—-这层的职责包含了三层的数据访问,但是并不代表UI层就可以调用数据访问的代码,而且职责范围扩充了,有人可能会把它当作存放公用代码的地方,但是建议这里只存放本项目公用的东西,如果能够跨项目公用的代码应该放在一个叫做“应用程序框架”的项目来完成,每个公司都应该有自己的应用程序框架。

回顾一下三层架构与DDD分层的区别:

a. UI层技术基本一样,一些比较智能的绑定可能无法进行了。

b. 服务层基本一样。

d. 业务实体+业务逻辑 = 领域层

e. 如果三层架构不采用业务实体与数据表一致的做法,这层也是一样。

TML标题分割线=======================

开发过程回顾

典型的三层架构开发过程

三层架构以数据库为核心,首先根据需求建立数据模型,然后根据数据模型建立数据库,再根据数据表结构自动生成业务实体,然后可以同时进行业务逻辑及用户界面的开发。

1,一旦开发中业务有所变动,那么首先要修改数据库,重新生成实体,然后其他开发小朋友才能继续工作,网络连接不好、数据库挂机、数据库管理员未能及时更新数据库等等原因都会导致开发过程被打断,好处是终于可以休息一会,坏处是由于要赶进度晚上可能得加班。

2,经常变更数据库结构总不是一件愉快的事情,为了避免数据库结构变动,要求编码阶段之前尽量要把需求固定下来,中后期越少变动越好。由于业务逻辑与数据库绑定紧密,所以单元测试困难重重。当性能出现问题的时候,到底是代码逻辑没有写好,还是Sql语句没有写好,诊断有点困难。由于类的粒度太大,设计模式罕有用武之地,设计原则跟自己没有关系,久而久之可能会觉得编程思想都是骗人的。

DDD开发过程

DDD以领域模型为核心,首先根据需求建立领域模型,然后根据领域模型建立代码模型,然后就可以同时开发业务逻辑和用户界面了。

1,我们有一个模拟数据库存储接口的内存数据库,因此这时候不需要考虑数据库,如果这时业务发生变化,直接修改对象结构是非常简单的事情。直到开发后期,所有功能都已经开发完成,业务结构也稳定下来了,我们再根据领域模型建立数据库,进行一个简单的与业务逻辑集成就完工了。

2,免除了开发过程中数据库经常变动的烦恼,开发过程不会被打断,随时可以进行单元测试,随意可以与用户界面集成把系统跑起来,开发逻辑的时候不考虑数据库,开发数据库的时候不考虑业务,关注点更加集中了。出现性能问题可以单独测试数据库组件和业务逻辑组件,更容易定位问题。类的粒度很小,各种重用,各种设计思想都纷纷派上用场,感觉终于跟国际接轨了。

初识DDD

经过了以上博文的阅读归纳后,话是有些不知所以,觉得隐约确实好一些,但好处体现的似乎很模糊,初步体验就是三点:

1,开发初期邀请领域专家介入,使用通用语言沟通,更好的明确需求与业务。

2,将对数据表驱动开发的模式思路转换为业务,领域驱动开发的模式思路。具体操作就是,先建立领域模型,而不是数据模型,这样便于后期的修改和扩展。

3,将单纯的实体改为领域对象,使用充血模式开发,而不是贫血模式开发,这样不容易导致健忘症。

之后在看一本vaughn Vernon的《实现领域驱动设计》一书,会逐渐更新这方面的博客,争取在自己有架构能力(虽然很遥远)的时候实现直接使用领域驱动开发模式来架构。

相关文章
|
2月前
|
运维 监控 负载均衡
动态服务管理平台:驱动微服务架构的高效引擎
动态服务管理平台:驱动微服务架构的高效引擎
53 17
|
2月前
|
监控 Java 持续交付
后端开发中的微服务架构实践与挑战####
在当今快速迭代的软件开发领域,微服务架构以其灵活性和可扩展性成为众多企业的首选。本文探讨了微服务架构的核心概念、实施策略及面临的主要挑战,旨在为后端开发者提供一个全面的指南。通过分析真实案例,揭示微服务在提升系统敏捷性的同时,如何有效应对分布式系统的复杂性问题。 ####
|
2月前
|
消息中间件 API 持续交付
后端开发中的微服务架构实践####
【10月更文挑战第21天】 本文深入探讨了微服务架构在后端开发中的应用,从基本概念出发,详细阐述了微服务的核心优势、设计原则及关键技术。通过实际案例分析,揭示了微服务如何助力企业应对复杂业务需求,提升系统的可扩展性、灵活性与可靠性。同时,也指出了实施微服务过程中可能面临的挑战,并提供了相应的解决方案和最佳实践。 ####
41 3
|
14天前
|
监控 JavaScript 数据可视化
建筑施工一体化信息管理平台源码,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
智慧工地云平台是专为建筑施工领域打造的一体化信息管理平台,利用大数据、云计算、物联网等技术,实现施工区域各系统数据汇总与可视化管理。平台涵盖人员、设备、物料、环境等关键因素的实时监控与数据分析,提供远程指挥、决策支持等功能,提升工作效率,促进产业信息化发展。系统由PC端、APP移动端及项目、监管、数据屏三大平台组成,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
|
2月前
|
消息中间件 监控 持续交付
后端开发中的微服务架构设计与实践####
在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用的关键策略。本文将深入探讨微服务架构的核心概念、设计原则与实战技巧,通过实例解析如何在后端开发中有效实施微服务,以应对复杂业务需求和技术挑战。我们将从微服务的拆分策略、通信机制、数据管理到持续集成/持续部署(CI/CD)流程,全面剖析其背后的技术细节与最佳实践,为读者提供一份详尽的微服务架构设计与实践指南。 ####
105 31
|
1月前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
101 3
|
1月前
|
前端开发 搜索推荐 安全
陪玩系统架构设计陪玩系统前后端开发,陪玩前端设计是如何让人眼前一亮的?
陪玩系统的架构设计、前后端开发及前端设计是构建吸引用户、功能完善的平台关键。架构需考虑用户需求、技术选型、安全性等,确保稳定性和扩展性。前端可选用React、Vue或Uniapp,后端用Spring Boot或Django,数据库结合MySQL和MongoDB。功能涵盖用户管理、陪玩者管理、订单处理、智能匹配与通讯。安全性方面采用SSL加密和定期漏洞扫描。前端设计注重美观、易用及个性化推荐,提升用户体验和平台粘性。
65 0
|
1月前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
2月前
|
监控 Serverless 云计算
探索Serverless架构:开发实践与优化策略
本文深入探讨了Serverless架构的核心概念、开发实践及优化策略。Serverless让开发者无需管理服务器即可运行代码,具有成本效益、高可扩展性和提升开发效率等优势。文章还详细介绍了函数设计、安全性、监控及性能和成本优化的最佳实践。
|
1月前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
50 1

热门文章

最新文章