为什么需要从按技术分层(dao,控制器,实体)转移到按业务功能(userMgmt,productMgmt)打包?- phauer

20-04-22 banq

一种流行的方法是出于技术考虑进行包装Package。但是这种方法有一些缺点。相反,我们可以按功能打包并创建自包含且独立的程序包,结果是一个易于理解且不易出错的代码库。

  • 按技术打包类的缺点:

    • 对属于某个要素的所有类的概述不佳。
    • 通用代码,重用代码和复杂代码趋向于难以理解,并且由于难以把握变更的影响,因此变更很容易破坏其他用例。
  • 按业务功能打包并创建包含功能所需的所有类的程序包。好处是:

    • 更好的可发现性和概览
    • 独立且独立
    • 更简单的代码
    • 可测性

逐层打包

项目结构的一种非常流行的方法是逐层打包。这将为每个技术组的类提供一个软件包。

让我们将调用层次结构添加到图片中,以“清楚地”看到哪个类取决于哪个类。

那么,按技术层打包的缺点是什么?

  • 功能概述不佳。通常,当我们在项目中处理代码时,我们会想到要更改的特定领域或功能。因此,我们从领域的角度出发。不幸的是,按技术打包迫使我们从一种包装过渡到另一种包装,以掌握整个业务功能的概况。
  • 通用,重用和复杂代码的趋势。通常,这种方法导致中心类包含每个用例的所有方法。随着时间的流逝,这些方法越来越抽象化(带有额外的参数和泛型)来满足更多用例。仅在上述画面的一个例子是ProductDAO,其中用于所述方法ProductController和ExportController所在的位置。结果是:

    • 当添加更多方法时,类将变得更大。因此,仅凭代码量,就很难理解它。
    • 更改通用重用代码很危险。尽管您只想处理一个用例,但您可以轻松地打破所有用例。
    • 由于以下两个原因,难以理解抽象方法和通用方法:首先,要通用,通常需要其他技术构造(例如,switch,参数,泛型),这使得查看与之相关的业务逻辑更加困难。当前用例(信号噪声比)。其次,认知需求更高,因为您必须了解所有其他用例,以确保不会破坏它们

我们虽然实现了DRY,但违反了KISS。

按业务功能打包

让我们将这些类重新排列成独立的功能包。

新程序包userManagement包含属于此功能的所有类:控制器,DAO,DTO和实体。

新软件包productManagement包含相同的类类型,再加上StockServiceClient和StockDTO。这个事实清楚地表明:库存服务仅由产品管理人员使用。

userManagement和productManagement使用不同的域实体和表。将它们分成不同的包很简单。但是,当一个功能需要与另一个功能相似域实体时,会发生什么?

现在,它变得越来越有趣。产品导出功能包的软件包exportProduct还处理产品实体,但是具有不同的用例。

我们的目标是拥有独立的独立功能包:exportProduct即使看起来可能类似于productManagement,似乎不应该具有自己的DAO,DTO类和实体类。抵制重用productManagement中类的冲动。

  • 我们可以使用针对export用例量身定制的结构(DTO,实体)。它们仅包含相关字段,并且可以基于具有相关列的良好投影的查询来创建实体-别无其他。
  • 专用ExportProductDAO包含特定于export的查询和预测。

我们可能不得不再次编写更多代码,但最终会遇到非常有利的情况:

  • 更改productManagement将永远不会破坏exportProduct代码,反之亦然。它们可以独立发展。
  • 更改代码时,我们仅需牢记当前功能。
  • 代码本身将变得更加简单易懂,因为它不是通用的,并且不必在两个用例中都可以使用。

上面的功能包很棒,但实际上,我们将始终需要一个common包。

通用软件包包含技术配置和可重复使用的代码

  • 它包含技术配置类(例如,用于DI,Spring,对象映射,http客户端,数据库连接,连接池,日志记录,线程池)
  • 它包含可以重用的有用的小代码段。但是,过早抽象代码要非常小心。我总是首先将util代码尽可能地接近其用法,这是功能包甚至using类。仅当我确实对代码段有更多用法(不是:我认为将来可能会使用)时,才将其移动到common程序包中。该三个规则给出了很好的指导。
  • 它可能是有意义的定位在所有实体common包。我们还对某些项目执行了此操作,其中许多功能包一次又一次地使用相同的实体。一些开发人员还希望将所有实体放在中心位置,以便能够整体查看数据库架构的映射。在这一点上,我并不信条,因为实体的两个位置都可以合理。尽管如此,我始终总是开始将尽可能多的代码移至功能部件包,并依赖于量身定制的特定于用例的实体和预测。

 大图景

最终,我们的战略大图景看起来像这样:

让我们简要总结一下好处:

  • 从域的角度来看,更好的可发现性和概述。属于业务功能的大多数代码位于一起。这很关键,因为我们通常会在考虑某个业务需求的情况下访问代码库。
  • 独立的和独立的。功能所需的大多数代码都位于程序包中。因此,我们避免依赖其他功能包。结果是:

    • 我们在开发功能时破坏其他功能的可能性较小。
    • 需要较少的认知能力来估计变化的影响。通常,我们只需要记住当前的软件包即可。
  • 更简单的代码。由于我们避免使用通用和抽象的代码,因此代码变得更加简单,因为它只需要处理一个用例。因此,更容易理解和发展代码。
  • 可测性。通常,与试图满足所有用例的技术包中的“上帝类”相比,功能包中的类具有较少的依赖关系。因此,由于我们必须创建更少的测试夹具,因此测试变得更加容易。

缺点

  • 我们必须编写更多代码。
  • 我们可能会多次编写类似的代码。
  • 决定何时最好将代码移至common程序包并重用它是很难的。有疑问时,“三定律”很有用。

我想强调指出,重用仍然是允许且有用的。我们不会在教条上采用这种方法。

但是,我认为优点大于缺点。

背后的原理

提出的按功能打包的方法遵循了一个非常贴切的原则:

KISS>DRY

再次,我想引用桑迪·梅斯(Sandi Metz)

“优先选择复制而不是错误的抽象。” 桑迪·梅斯(Sandi Metz)。参见编码智慧之墙

按功能打包案例

我们的团队记录了其遵循的编码准则和原则。关于按功能打包的部分如下所示:

我们基于功能打包代码。每个功能包均包含提供该功能所需的大多数代码。每个功能包都应独立且独立。

├── feature1
│   ├── Feature1Controller
│   ├── Feature1DAO
│   ├── Feature1Client
│   ├── Feature1DTOs.kt
│   ├── Feature1Entities.kt
│   └── Feature1Configuration
├── feature2
├── feature3
└── common

  • 这种方法影响所有层。例如,每个程序包都有自己的DAO和客户端。不应有庞大的DAO类神。
  • 一个程序包应该与其他程序包只有几个关系。该功能所需的所有物品都应放在包装内。
  • 经验法则:如果要删除功能,则只需删除相应的程序包。
  • 仍然可以重复使用common软件包中的内容,但它只应包含多次使用的代码(请参阅三则规则)。它不包含业务逻辑。技术人员还可以。
  • 如果有特定于功能的Spring Bean,我们会将其配置放在功能包中。

问题

1. 功能包有多大?

术语“功能”很棘手。“产品export”是功能吗?抑或是更大的“产品管理”功能的一部分(包含许多其他内容)?在这种情况下,您也可以将其称为“ 模块 ”。我不想为此提供任何指导,只要您构建从您的域派生的独立且自包含的包/模块,您就走上了正确的道路。实际范围取决于域,您的喜好以及要在此模块中重用的数量。

2.功能包可以包含子包吗?

绝对没错。由于包装的大小可以变化,因此在包装内提出子包装结构是有意义的。在要素包中逐层打包也是合理的。如果有帮助,您可以考虑使用“模块”而不是“功能包”。

3.我最终会一次又一次写相同的代码吗?

是的,会有一些重复,但是根据我的经验,您可能不会相信那么多100%相同的代码。由于相似的代码涵盖了不同的用例,因此通常是不同的。例如,两种方法可以按产品名称查询产品,但是它们在计划的字段,排序和其他条件方面有所不同。因此,最好将方法分开放在不同的程序包中。

而且,复制本身并不是邪恶的。在开始将代码提取到通用重用方法之前,我喜欢应用三规则

最后,我想强调指出,仍然允许集中使用可重用的代码,有时甚至是合理的,但是这些情况不再那么常见了。

4.Kotlin可以支持这种方法吗?

打包方法与语言无关。但是Kotlin使其易于遵循:

  • 使用数据类,编写量身定制的特定于功能的结构(如DTO或实体)仅需几行,而无需样板。
  • Kotlin允许将多个类放在一个文件中。因此,对于每个POJO类,没有子包dtos或entities包含很多Java文件,我们可以有一个包含所有数据类定义的文件DTOs.kt或Entities.kt文件。

                   

1

猜你喜欢