领域驱动设计-让程序员心中有码(九)

一、易于腐化的软件设计

犹记得刚刚参加工作时,是地图厂商四维图新集团旗下的一家子公司,主要从事规划测绘相关软件研发的公司。当时我的项目是为勘测设计院提供相对应的应用软件,对地理信息和规划相关的图纸信息,几乎已经专业水平。事实上,规划设计大概和软件设计类似,有规划的设计、或无规划的设计,造成的结果几乎是天壤之别。

我们或许很容易就能设想到一个毫无规划设计的城市,纵横交错的路网、杂乱无章式的建筑布局、各种凌乱的棚户区设计,恰好象征着软件设计的无序性,也恰好体现了软件企业在经费不足、组织缺乏管理、开发者能力不足、软件随时随地想改就改时的行业现状,只能说这样的软件是最能符合当时实际劳动生产力水平的产品。

如图一所示,巴西棚户区,层层叠叠、风格迥异、密密麻麻,如果作为一个外人贸然来到这样的地方,大概很容易迷失期间、更不用说充斥在棚户区的各类毒品和黑社会。杂乱无章的建筑和街区,就像代码中错综复杂的调用链;而借助贫民区搞事的黑社会就像是代码中的异味或者bug,表面上看起来如此平静、与世无争、但是你永远也不知道啥时候会来一冷枪。

不要以为离我们很远,我们其实轻易就能写出这样的软件工程项目。不一定是“大泥球”系统,也有可能只是一些看似简单的业务系统,但内部代码逻辑,可能会复杂到令人窒息的程度。也许那个时候有个别开发者也许会试图靠自己的能力来改变局面,但是往往也会碍于屎山太大,难以下咽。

大概只有最顶级的规划设计师、耗费足够多的资源,才能将这样的软件系统进行整改。然而,即便如此,如果以后没有持续维护的手段、更好的设计、仅靠老程序员或个别架构师、盲目相信将单体服务拆分成微服务,几乎不太可能实现软件未来的可持续发展。

一个良好的软件产品的一生、或许其实是一家企业一生的真实写照。

在特定组织架构下,缺乏技术基因的组织有时候期待技术变革,却会开启新的泥坑。而那些渴望靠技术改变一切的技术专家,虽然拥有某些大厂微服务式架构、以及架构改造的经验,他们也试图通过自己的努力,为企业业务腾飞助力。而在他们过去的经验中,往往相信组织遇到的问题,用微服务一定能解决问题。然后大肆扩招,一年内从几个人的规模、扩招到数百人的规模,将原来的系统从单体服务、改良成为微服务。但是靠单枪匹马根本无力拯救大势,没有更好的业务拆分策略,就只能按照数据库的表名关系实现了最简单的拆分。架构改造并非每次都会百试百灵,有时甚至连原来的需求都包不住,毕竟只能看到用户界面层外观上的表面逻辑,而隐藏在业务中的那数十万行代码,哪怕包含了企业最有价值的经验财富,也由于代码过于混乱,最终抛弃在源代码管理器中,堪称化神奇为腐朽。

二、易于腐化的面向过程开发

老系统改造也好、新系统开发也好,毫无疑问,我们最容易相信的其实是老程序员经验,而程序员们掌控系统的方式,就是靠数据库建模来驱动软件开发的古老模式,而且几乎都是面向过程式的代码,这些代码的流程几乎一模一样,只需简单的按照步骤,一步步套模式,轻易就能学会。

1、查看用户界面,定义需要绑定到界面的模型和层级结构。

2、设计数据库,不管什么类型的项目,先根据客户提供的业务表单、将其转化成实体关系(ER图)、然后建立对应的代码模型。有可能使用专业软件设计ER图,也有可能会使用Navicat软件设计ER图。

3、设计接口,然后把数据拼凑成用户界面层所需的对象。

4、代码层次结构为传统的三层架构,严格按照用户界面层、业务逻辑层、数据访问层进行设计,有时候会引入依赖注入框架,实现不同层次间的解耦。

但是有时候程序员不会严格区分需要编写的代码,究竟是属于哪个层次应该囊括的内容。于是毫无疑问,如果代码是为了实现用户界面上某些数据绑定操作,代码就往用户界面层写;或者代码是为了实现从数据库中抽取某些复杂数据、并构造成满足用户表现层逻辑的查询对象,那么就可以看到数据访问层代码中那些臃肿的SQL语句或查询方法。

正如“罗马不是一天建成的”,屎山也同样如此。这样的写法在代码刚刚编写之初并没有问题,只是随着业务变化、时间的积累、程序员的水平、方法重构、新技术新组件的引入,代码将成为屎山。

这时,高级程序员们的价值,就在于他如何能够在屎山中快速找到bug、并解决问题的能力,这大概是一种不能复用、不可再生的能力,因为永远有让人看不懂的垃圾代码,而且每家企业都有自己的特点,不同企业间往往不能循环利用。我一位朋友经常吐槽,他感觉自己的价值就是守住公司那份拥有8年历史的古老代码,以便其他程序员在进行代码修改时,不会引发莫名其妙的bug让系统无法运转。

三、过程式开发和事务脚本模式

在现代软件工程学的教科书中,都会指出面向对象是解决软件复杂性的方法,但实际上掌握这种方法的开发者并不多。由于开发者普遍缺乏抽象化思维,所以面向数据库、面向过程式的编程习惯能够成为业界主流,并非时代的倒退,而仅仅只是在短期效率和长期维护性上,被迫做出的艰难选择。

假设我们设计出的符合三层架构的系统结构图简化后,如下图所示:

我们来看看这种数据库建模的开发流程中的输出成果:

1、会定义两种对象,分别是是面向UI层的模型(DTO)和数据实体(Entity)。在领域驱动设计中,将这两种称为所谓贫血模型,贫血模型,只有赋值器Set和取值器Get,(在Java里面会使用POJO 这个名词来定义)。贫血模型是为了作为保存状态或传递对象而存在,他并非按照实际用例场景对某类具体事务的抽象、也没有与对象相关的行为。

2、定义数据访问层来实现数据的持久化、或者从持久层实现数据的创建过程。数据访问层存在的目的是为了构建上述贫血模型对象,这种访问机制被成为“事务脚本”。事务脚本与对象行为割裂,而且容易导致异味产生。

3、与用户行为相关的操作割裂的存放在不同层。有的可能放在用户界面层、有的可能放在数据访问层、有的可能放在业务逻辑层,造成了领域知识的丢失。

4、用户界面层使用接口作为外观或者一种行为、开发者会使用自己独立的风格习惯来定义这种行为,就容易造成术语和规则不统一,也会为后期产品的维护迭代造成问题。

5、现在的软件设计,往往要求输出一份高保真的原型图、也会按照敏捷项目管理的流程对这份原型图建立持续更新的机制,确保原型图是需求的具体表达,但是产品语言并非统一语言,也许产品语言具有业务含义,但是由于不能指导开发者进行接口、类、持久层的设计,造成了代码与需求的割裂。在张逸老师的《领域驱动战术实践》提到他曾经使用dimension和metric两种不同的对象来定义一个维度对象,为代码造成了不必要的麻烦。我也曾经在一个项目,遇到过产品术语未能澄清,导致开发中使用style和theme两种截然不同的定义来定义与“风格”相关术语,为代码引入了不必要的纠结。

四、领域驱动设计是什么?

领域驱动设计引入了以下概念,但是我们无需在这篇文章中深刻理解这些概念的具体含义,我们只需知道,有这个东西。当我们开始按照领域驱动设计的方法设计一个系统时,按照前人整理的领域驱动的sample,往往就会将概念融汇贯通,达到更好的理解效果。

1、统一语言:定义好产品原型,需要建立统一语言。这是一种在内部和外部都能使用的规范化用语,包括UML、适当的图、一致性的描述、以及专业术语和术语对应的英文描述。

2、实体:在领域中可以通过标识进行唯一值定位的对象。

3、值对象:在领域中,从其他领域或某个实体中分离出只包含某些特定属性的对象。由于不具备唯一性特征,往往无需用于数据持久化。

4、聚合、聚合根:将具有相关性的对象聚合在一起,并以聚合根的形式统一对外提供访问方法和属性字段成员。

5、限界上下文:领域包含核心领域、子域和通用子域,而限界上下文则是一个具体业务的流程。每个限界上下文独立于其他限界上下文而存在,独立演进、功能完备。限界上下文的识别充满技术含量。

6、领域服务:包括仓储服务和工厂服务,前者负责实现对象与数据库的操作过程、封装了一系列数据库操作的方法;后者则侧重于对象的创建过程。个人认为从三层架构演进到领域驱动架构过程中,仓储服务是最接近于数据访问层的逻辑,也是让大部分领域驱动架构最终又回归到三层架构的一种通病。从对数据访问层中抽出对象、行为、数据访问,是战术设计的关键步骤。

领域驱动设计引入了一堆新的架构形式,包括经典的四层架构、EDA(事件驱动架构)、CQRS架构(命令查询职责分离)。而由于Evans的原书没有过分讨论如何识别领域,后来又有许多大佬在他的基础上进行了完善,提出了许多方法,包括名词、形容词、动词建模法、事件风暴、四色建模等方法,限于篇幅,且听下回分解。

五、思维的转变,才是最大的困难

领域驱动设计,或许是解决这些问题的一剂良方,但也或许是开启了暗黑世界的大门。

概念晦涩难懂、程序员们不愿意开始思维变革、技术上可能存在不预期的坑、都可能让新方法的实践陷入一滩烂泥。还有许多人以为自己看懂了领域驱动设计(包括笔者),在往项目中运用时,总是有意无意的会被过程式代码的思维定式控制,让架构回退到三层架构。

由于微服务架构的兴起,让复杂系统的开发维护成为大家普遍关心的问题,使得Eric Evans于十五年前提出的这套理论,在今天绽放出了新的光芒。当然领域驱动设计仅仅只是众多面向对象编程的一种实践,通过领域驱动设计将UML等方法灵活的运用其中,通过打破原有数据库关系建模给代码造成的桎梏,让开发者能够真正的实现面向对象编程。

然而思维模式的转换并非易事,从过程式代码中,抽离出与对象有关的行为,远比理解这几个概念要复杂,这需要大量经验的积累。

毋庸置疑,数据库建模驱动软件开发具有速度快、学习成本低的显著特点,在许多项目中,能在短期内可以给开发者带来许多便利;而应用领域驱动设计,则可以在更长的维护周期内,给软件维护带来实质性好处。

两种不同类型的开发模式,根据企业实际出发进行选择,还只是开始,但能真正运用好领域驱动设计或者UML、面向对象设计这种软件工程的美学思维来改造我们的系统,让系统绽放出更加璀璨的光芒,这才是软件设计的乐趣所在。

原文地址:https://www.cnblogs.com/xiyuanMore/p/11800314.html

时间: 2024-10-24 19:33:48

领域驱动设计-让程序员心中有码(九)的相关文章

领域驱动设计,让程序员心中有码(七)

领域驱动设计- 让程序员心中有码(七) -设计原则和设计模式,互联网开发者们共同的追求 前言 多年来,笔者一直从事传统软件企业的软件开发和项目管理工作.笔者发现在众多的传统软件企业中,评判优秀开发者的标准往往是技能的熟练程度,基本上都是以梭代码的速度论英雄.有人评价说,这种开发可以称之为cv编程,即ctrl+c和ctrl+v编程为主.这种开发往往对开发者的技能要求并没有想象中的那么高,由于工时和合同的限制,不得不压缩开发时间,通过靠密集的劳动力资源.较高的工作强度来完成项目的开发.这种模式,通过

领域驱动设计,让程序员心中有码(二)

  引子,软件工程没有银弹    上一篇博文,抛出了一个问题,领域驱动设计真的是万能的良方吗?对于这个问题,大家的答案无疑是一致的,作为一种非常受软件行业欢迎的软件思想,领域驱动设计固然有很多优点,却并非万能.  回到十年前,第一节软件工程学的课堂上,我们的老师就告诉了我们一句真理,软件工程没有银蛋,这句话说的是,软件工程领域,从来没有一种思想或理论能够带来成倍的效率提升.不知不觉,十年过去,我们大概可以看到,软件开发新技术日新月异,新语言层出不穷,但是无论哪种技术,都不见得相对于其所对标的技术

领域驱动设计,让程序员心中有码(五)

1      从搬砖谈领域对象 有一个古老的故事,大概是这样的.作者问三个建筑工地上的工人他们在干什么?有一个没精打采的说,我在挖洞!而另一一个人却说,我在盖一座房子.还有一个人说,我在建立一座巨大的城市.不同的思维模式决定了不同的发展,十年过后,第一个工人,还是在挖洞,而第二个则成为了工头.第三个最终却成为了大设计师. 在软件开发领域,往往会使用搬砖这个词来形容我们所开发的每个功能模块,实际上也确实如此,如果把我们需要完成的每个项目,比作一座高楼大厦,那么在项目中所完成的各种模块,也确实是我们

领域驱动设计系列(转)

曾经参与过系统维护或是在现有系统中进行迭代开发的软件工程师们,你们是否有过这样的痛苦经历:当需要修改一个Bug的时候,面对一个类中成百上千行的代码,没有注释,千奇百怪的方法和变量名字,层层嵌套的方法调用,混乱不堪的结构,不要说准确找到Bug所在的位置,就是要清晰知道一段代码究竟是做了什么也非常困难.最终,改对了一个Bug,却多冒出N个新Bug.同样的情况,当你拿到一份新的需求,需要在现有系统中添加功能的时候,面对一行行完全过程式的代码,需要使用一个功能时,不知道是应该自己编写,还是应该寻找是否已

领域驱动设计系列(3)有选择性的使用领域驱动设计

本系列的第一篇博文抛砖引玉,大谈领域驱动设计的优势,这里笔者还是希望以客观的态度,谈谈领域驱动设计的缺点及其不适合使用的场景,以让读者可以有选择性的使用领域驱动设计. 我们知道,没有最好,只有最合适,设计也是一样.因此,所谓设计,就是以你和你的团队的知识.经验和智慧,全面充分的考虑各种内外因素后,在你们的设计方案中作出合理的选择的过程.而这些影响你们选择的因素主要有: 技术框架的特征和约束(如果你的项目决定使用C语言进行开发,那么首先在设计方法上,就需要使用面向过程而非面向对象的设计方法). 时

领域驱动设计系列文章(3)——有选择性的使用领域驱动设计

本系列的第一篇博文抛砖引玉,大谈领域驱动设计的优势,这里笔者还是希望以客观的态度,谈谈领域驱动设计的缺点及其不适合使用的场景,以让读者可以有选择性的使用领域驱动设计. 我们知道,没有最好,只有最合适,设计也是一样.因此,所谓设计,就是以你和你的团队的知识.经验和智慧,全面充分的考虑各种内外因素后,在你们的设计方案中作出合理的选择的过程.而这些影响你们选择的因素主要有: 技术框架的特征和约束(如果你的项目决定使用C语言进行开发,那么首先在设计方法上,就需要使用面向过程而非面向对象的设计方法). 时

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型:

从三层架构迈向领域驱动设计

本文读者基本要求:从事信息管理系统开发,略懂GOF设计模式及SOLID设计原则,对三层面向过程机械编码厌倦,并且不知道出路在何方,如果还掌握代码坏味和重构手法,那是极好的. 1. 三层架构 理论介绍-->实际经验-->总结反思 1.1 简单介绍三层架构 严格分层架构模式的特点是上层只能访问相邻的下层,其他层次间的调用都不允许.三层架构就是一种严格分层模式,它把职责划分为界面展示.业务逻辑.数据访问三层,还有一个业务实体,前面三层都要依赖它,所以它并不构成一个层.结构如图1. 三层架构的特点是一

[转]DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型: