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

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

-设计原则和设计模式,互联网开发者们共同的追求

前言

  多年来,笔者一直从事传统软件企业的软件开发和项目管理工作。笔者发现在众多的传统软件企业中,评判优秀开发者的标准往往是技能的熟练程度,基本上都是以梭代码的速度论英雄。有人评价说,这种开发可以称之为cv编程,即ctrl+c和ctrl+v编程为主。这种开发往往对开发者的技能要求并没有想象中的那么高,由于工时和合同的限制,不得不压缩开发时间,通过靠密集的劳动力资源、较高的工作强度来完成项目的开发。这种模式,通过简单的复用历史代码,可以更快的输出结果,对于中小型企业和一些外包企业来说,也意味着更快的项目完成速度、而越快做完项目,也意味着可以越快收回合同款,尽快开始下一个项目。

  然而,也必须承认,在这种模式下,代码的质量取决于项目管理者对于技术和代码的把握能力,如果摊上不懂技术的项目管理者以及对于代码质量没有要求的研发人员,可能最终输出的代码,将成为一团乱麻,只能在一个个项目中无穷次的积累,直到遇到一群优秀的开发人员费劲心力把体系重构为止。

  而当今互联网时代下,面向互联网的应用开发,不再追求短期成效,更在乎长期技术的沉淀,这个过程中,也对开发者提出了更高的要求。互联网行业的开发者,不仅仅要求代码梭得快,还在乎编写代码编写的质量,谁能编写出更加优美的代码,往往也更容易受人欢迎。于是,作为优美代码代名词的SOLID设计原则和很多种设计模式实际上成为了非常基础的一种能力,甚至于许多资深的开发者,经常会乐此不疲的进行各种代码的重构,也是期待能够更好的将设计模式揉碎了,应用到代码中,更好的实现高内聚、低耦合的目标。

《head first》中的工厂模式

   在著名小红书《Head First》一书中,描述了多种设计模式,这些由资深IT技术大牛们抽象化出来的最佳代码实践,初读起来也许简单明了,但是细细品味起来,却意味深长。

   在传统软件开发实践工程中,往往会下意识的使用New关键字产生对象实例。通过这种方式进行代码的编写,固然会带来代码上的开发速度,但是同样也会给对象的生成带来一些问题。例如,对象的构造,往往附带了许多复杂的条件:如需要进行一些初始值的设置,如需要初始化与之相关的子类,或者需要预先执行许多初始化方法,那么就可能意味着代码的构造中会产生一系列复杂、与主流程无关的代码。如何让轻松方便的构造代码、而不去关心具体的实现细节呢?

  工厂模式成为解决问题的方案,通过工厂模式,适当的创建接口,将代码中的具体过程进行屏蔽,从而提高了代码的灵活性。又分为静态工厂、简单工厂模式、工厂方法模式、抽象工厂模式等多种不同的模式。例如,我们可能会编写一段下面的代码。

 1 public abstract class FactoryPizzaStore
 2 {
 3         public Pizza OrderPizza(string type)
 4         {
 5
 6             Pizza pizza = CreatePizza(type);
 7             return pizza;
 8         }
 9         public abstract Pizza CreatePizza(string type);
10 }

  我们可以看到,这只是一段最普通的工厂代码,定义了一个抽象对象,如果需要实现成员,只需继承此对象,并重载方法,这种方法可以非常便捷的将内部对象的创建过程进行封装,实现了代码内聚性的显著提高。

领域驱动中的工厂模式和仓储模式

在领域驱动中,将工厂模式引入其中,让其产生了不同的含义。在上一章,我们了解到,随着软件系统复杂性的显著提高,维护模型实例的生命周期变成了一件非常困难的事情,因此通过引入一个聚合Aggregate对象,可以有效的将复杂的模型复杂的生命周期的各个阶段进行封装,通过一系列固定的规则,实现了对数据更加的控制。而这种控制,则是通过工厂模式和仓储模式来实现的。这两种模式,实现了对Aggregate对象的操作,实现了复杂的生命周期转换复杂性的良好封装。

领域工厂模式

  一个复杂的软件系统,往往如同生产一台汽车,它由许多个不同的部件组成,每个部件间通过一系列复杂的协同运动来实现整体的职能。对于用户而言,汽车是如何装配的,并不是他所关心的问题,他只在乎如何驾驶这辆汽车。这意味着,装配过程,应该与对象要执行的工作分开。软件系统同样如此,我们设计了一个复杂的聚合对象,这个对象内部有大量的实体或者值对象。如果开发者需要使用这个对象,必须按照一系列规则来进行操作。

在这个聚合对象的生命周期中,如果将创建的过程按照调用的场景,分拆到不同的环节中,可能使代码的耦合性急剧提高,带来的将是后期高昂的更改成本。

  在领域驱动设计中,复杂对象的创建过程往往是领域层的核心职能,但是,对于这个复杂对象创建过程,又显然不能有简单的Service对象来实现,因此,需要引入工厂模式。封装创建复杂对象或聚合对象

的全部规则,并通过提供相关接口、创建对象的抽象视图,让创建的过程符合规则。

  在领域工厂模式中,往往有以下要求:

1、创建过程的原子性、满足创建所需的所有规则。由于我们引入工厂的目的,是为了将复杂的常见过程进行封装,因此我们应当确保创建过程要产生一致状态的对象。例如创建实体,应当满足聚合的全部规则、创建值对象,应该被设置为默认的参数,如果无法创建参数,应该抛出异常,或者提供处理机制,确保不会影响代码的执行。

2、工厂模式是一种抽象对象,而不是具体对象。意味着这个过程,不会产生具体对象,也就避免了与下层对象间不必要的耦合。

工厂模式不仅仅可以应用于对象生命周期的开始阶段,也可以在对象的重建过程中发挥作用,例如在使用关系型数据库和非关系数据库组成的复杂体系中,通过对象映射技术,可以实现对现有数据的装载。

领域仓储对象

  在软件系统研发过程中,我们通常需要使用SQL语句,直接调用基础设施层中的某个方法,实现了一系列数据转换。有时候,我们会引入AutoMap组件,实现从实体层到模型层对象的封装,这种模式广泛存在于我们的开发过程中,但是如果直接访问基础设施层,则可能增加对于数据库不必要的操作,并导致模型的价值可有可无。而且随着开发过程的推进,有可能会倾向于直接使用多次遍历的方式,提取具体对象,而忽略了Aggregate,并使得实体层成为单纯的数据容器。

  因此,通过引入仓储模式,可以为我们的实现过程提供便利。通过仓储模式,封装一系列数据库操作的方法,让我们的注意力更关注于模型中。客户端通过查询方法,向仓储中请求对象,然后再返回用户所需的对象。

  这段代码大概是这样的:

  

public interface IRepository<T> where T : EntityBase
{
    T GetById(int id);
    IEnumerable<T> List();
    IEnumerable<T> List(Expression<Func<T, bool>> predicate);
    void Add(T entity);
    void Delete(T entity);
    void Edit(T entity);
} 

  仓储的引入有很多优点:

  1、为访问者提供简单的模型,可用来获取持久化对象并管理他们的生命周期。

      2、实现数据源解耦。

      3、实现了对象访问策略的分离。

      4、便捷的访问内存对象,减少对数据库的吞吐压力。

  在仓储的设计过程中,应当注意一下事项:

      1、对类型进行抽象。仓储的目的是为了传递具有特定类型的实例,但并非每个对象都有一个仓储来与之对应。

      2、充分解耦。仓储聚合不同的查询方法,例如将关系数据库和缓存数据库的查询方法进行封装,使得代码的过程变得易于操纵。

   3、事务可控。提供事务操作的方式,便于用户自行实现事务的管理。

结语

在领域驱动设计中,通过在领域层中灵活的应用仓储模式和工厂模式,实现对象的创建过程和传递过程的不同阶段,可以让代码的执行过程更加的简洁、关系更加的清晰,这也将客观上有利于我们编写出更加优秀的代码。

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

时间: 2024-10-11 05:14:46

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

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

一.易于腐化的软件设计 犹记得刚刚参加工作时,是地图厂商四维图新集团旗下的一家子公司,主要从事规划测绘相关软件研发的公司.当时我的项目是为勘测设计院提供相对应的应用软件,对地理信息和规划相关的图纸信息,几乎已经专业水平.事实上,规划设计大概和软件设计类似,有规划的设计.或无规划的设计,造成的结果几乎是天壤之别. 我们或许很容易就能设想到一个毫无规划设计的城市,纵横交错的路网.杂乱无章式的建筑布局.各种凌乱的棚户区设计,恰好象征着软件设计的无序性,也恰好体现了软件企业在经费不足.组织缺乏管理.开发

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

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

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

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.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型: