1

该主题是指下面的解决方案，并想知道它在通用上下文和特定上下文中有什么缺点。

需要回答的问题：

  1. 在 Java 世界中应该为这种问题/应用程序选择什么样的架构？（一般上下文）
  2. 以下对应用程序建模的方法有什么缺点？
  3. 对于给定的上下文，提出的解决方案是否可以接受？（具体情况）

一般上下文：

我们有一种带有流处理主管道的应用程序。我们称这个应用为 AnimalSpecialDayCycle。将此视为“动物酒店的特殊日子”。

动物会一只一只来，酒店会为它们度过特别的一天，为它们提供食物、训练、繁殖和良好的睡眠。

让我们考虑一个贫血的域模型，例如：

Animal
    - gender
    DigestingSystem
        - type (vegetable|meat)
        - foodReservesLevel
    MuscoskeletalSystem
        - membersTypeSet (legs|wings|fins)
        - hasTail
        - musclesPowerLevel
    ReproductiveSystem
        - type (eggs|insemination)
    Mood:
        - energyLevel
        - happiness

建议的解决方案：

我们将此应用程序拆分为不同的模块（单独的应用程序），这些模块通过称为“动物”的通用域模型（转换为 JSON|XML）在它们之间进行通信。

Modules:
    EatModule
        EatServiceInterface (with method "eat(Animal)")
            - MeatEattingService
            - VegetableEattingService
    TrainModule
        TrainServiceInterface (with method "train(Animal)")
            - FlyableTrainService
            - RunningTrainService
            - SwimmingTrainService
    BreedModule
        BreedServiceInterface (with method "breed(Animal)")
            - EggsBreedingService
            - InseminationBreedingService
    SleepModule
        SleepServiceInterface (with method "sleep(Animal)")
            - FlyableSleepingService
            - LaydownSleepingService
            - StandingSleepingService
            - UnderwaterSleepingService

他们使用的动物和服务实施示例：

  • 狗（MeatEattingService、RunningTrainService、InseminationBreedingService、LaydownSleepingService）
  • 马（VegetableEattingService、RunningTrainService、
    InseminationBreedingService、StandingSleepingService）
  • Aligator（MeatEattingService、SwimmingTrainService、EggsBreedingService、UnderwaterSleepingService）
  • Parrot（VegetableEattingService、FlyableTrainService、EggsBreedingService、FlyableSleepingService）

现在，我建议在每个模块中扩展 Animal 域模型，例如：

public class AnimalEattingModel extends Animal {
    public EattingServiceInterface eattingServiceInterface;

    public void eat() {
        eattingServiceInterface.eat(this);
    }
}

其他模块也一样。

当动物进入一个模块并且我们从 JSON|XML（或任何 fromat 具有来自前一个模块的消息）创建对象时，我们还为该模块设置了正确的服务实现。

（例如：如果 Shark 进入 EatModule，我们将在其 eattingServiceInterface 字段上设置其类型的正确实现。）

实际上，我正在寻找一种保持多态性的方法，但要将行为与对象状态分开，保持贫血的域模型。

我看到的优点：

  • 在自己的类中解耦业务行为，能够轻松修改它们
  • 在这种面向服务的架构和贫血模型中，多态性和避免复杂的“ifs”结构和混乱的代码

缺点：

  • 依赖关系：域依赖于服务和服务在域上

具体上下文：

我们从头开始开发这种应用程序，假设我们已经完成了 50%（已经投入了大量精力）。

我们在每个模块中都需要“Animal”对象，因为在模块结束时，我们会发送一个带有 Animal 对象“新状态”的“事件”。

我对事情的发展方式不满意。现在，当我们进行开发时，我们只是在代码中打了很多“ifs”。

我们没有子类，因为当我提议创建它们时，我们不应该仅仅因为我们在一个字段上具有不同的值而创建子类，该字段可能只使用一次来执行“if”语句模块之一。

现在我认为我们需要的是多态性，但是没有机会摆脱 SOA 和贫血的领域模型，所以我在考虑上面的解决方案。

4

0 回答 0