干净的架构实体

Question

据我了解，清洁架构实体被布置为所有上层都直接或间接依赖的层，基于这样的假设：实体中的数据和业务规则是架构中最稳定的部分。

同时，实体包含父层所依赖的数据类，如果没有映射器用于数据，则其余的数据类。

但现实中的数据往往不够稳定。

下面是一个示例：假设您有一个用于销售汽车的应用程序。汽车数据由一个结构体来描述，其中包含描述、品牌、价格等参数。要求正在发生变化，现在，应用程序中与汽车混合在一起，应该有摩托车销售广告。有些字段与汽车相同，例如价格和描述，有些字段不同。

您无法将有关汽车和摩托车的数据放入一个结构中，因为这样就可以添加任何类型的广告，并且该结构将像癌瘤一样膨胀。

在更高级别实现多态行为也不起作用，因为这将生成结构本身的依赖项+层次结构中的循环依赖项，或者直接从上层到该结构的依赖项，这也很糟糕。当然，您可以在整个映射器链中重复此行为，但这需要很长时间并且会增加代码量。

仍然需要创建一个单独的数据类型和转发该数据的整个分支，这同样不方便，并且会在顶层添加依赖项。

给人的印象是，当数据发生变化时，清洁架构是脆弱的。

也许我不明白一些基本的东西，这个问题可以轻松解决吗？如果是这样，请写下到底是什么，如果不是 - 你能做点什么吗？）

Answer 1

我认为您将数据实体与业务实体或域实体混淆了。您的“稳定”一词也令人困惑。您似乎在谈论可扩展性：您的应用程序允许使用新功能或业务规则进行扩展的程度，或者修改将如何破坏您的应用程序。

干净的架构是关于应用程序架构，而不是主要是关于类设计。您提到的多态行为或数据类型是类级别的详细信息。

软件架构描述应用程序的结构，不处理实现细节或数据。就像建造一座建筑物时，建筑不涉及内部，而是涉及建筑物的结构。
这意味着应用程序处理的数据本身对架构没有影响。

我认为干净架构的关键是应用程序的干净结构，其中组件之间的依赖关系是从外到内的（见下图）。目标是创建具有强大业务逻辑的强大应用程序。
换句话说：更改 UI 或数据库不会影响业务逻辑。这使得该架构非常“稳定”（在可扩展性/修改方面具有鲁棒性）。
考虑到业务逻辑直接与 UI 或数据库交互/依赖于 UI 或数据库的架构，我们可以说该架构非常脆弱，因为修改 UI 也需要修改业务逻辑，即修改会破坏商业逻辑。清洁架构解决了这个问题。

您必须区分数据实体和业务实体。
数据实体保存业务逻辑所操作的数据。
领域实体封装了应用程序的实际业务规则（企业级）。

示例：一个应用程序旨在销售汽车。

类Car显然是一个数据模型，具有您所描述的属性，例如description, brand, price。您通常将此数据实体称为数据实体，因为它是业务逻辑所操作的数据的容器。例如，您可以用数据库中的数据填充该容器，并将其传输到视图层以进行显示和操作。用户操作该数据实体，然后将其返回到业务层。

这样的卖车应用的业务实体可以是RentalAgreement封装了租车规则的a、a LeaseAgreement、aPurchaseAgreement等等（根据实际企业业务而定）。这些类还包含相关逻辑，例如根据限制、税收、特别优惠或奖金等规则实际执行购买。这些实体可以反映企业级业务流程。

用例代表实际的业务逻辑。组合或操作业务实体以便为多个用例（或用户故事）提供服务的逻辑。例如，用旧车换新车。
遵循清洁架构，用例取决于实体，而不是相反（从外部到中心 - 参见上图）。因此，用例不依赖于例如演示者组件。它由演示者使用。

用例需要数据实体才能完成其工作。“以旧换新”用例需要一个Car实体存储旧车的相关数据，另一个实体Car存储新车的数据。
多态性是设计这些数据实体时应用的概念。

您可以引入一个抽象基类型Vehicle。然后通过推导 aCar和 a来实现这个类型Motorcycle。
广告应该是专用类型，例如Ads，它不是Vehicle类型层次结构的一部分。
您可以创建一个容器类型，例如Offer，它聚合 aVehicle和一个Ads实例。

在顶部，您创建一个eg OfferCreator，它创建Offer实例并选择适当的Ads。

这只是一个非常原始的例子。当遵循某些原则（例如 SOLID）时，遵循其模式可以提供高度的可扩展性。这意味着，添加新类型Vehicle或Ads不会破坏业务逻辑。扩展业务逻辑本身也不会破坏应用程序。