Недостаток архитектуры в размещении ссылки на сервис внутри модели домена?(Джава) - PullRequest
Новая
       27

Недостаток архитектуры в размещении ссылки на сервис внутри модели домена?(Джава)

0 голосов
/ 04 октября 2018

Тема ссылается на решение, приведенное ниже, и задаюсь вопросом, какие недостатки оно имеет в общем контексте, а также в конкретном контексте.

Вопросы, на которые необходимо ответить:

  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

Предлагаемое решение:

Мы разбили это приложение на разные модули (отдельные приложения), которыеобщаться между ними через общую модель предметной области, называемой «Animal» (которая преобразуется в 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

Пример использования животных и реализации службы:

  • Dog(MeatEattingService, RunningTrainService, InseminationBreedingService, LaydownSleepingService)
  • Лошадь (VegetableEattingService, RunningTrainService,
    ИнсекцияBreedingService, StandingSleepingService)
  • ПивингSering, 10 летПопугай (VegetableEattingService, FlyableTrainService, Служба разведения яиц, FlyableSleepingService)

Теперь я предлагаю расширить модель домена Animal в каждом модуле, например: 

public class AnimalEattingModel extends Animal {
    public EattingServiceInterface eattingServiceInterface;

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

То же самое для других модулей.

Когдаживотное входит в модуль, и мы создаем объект из JSON | XML (или того, что fromat имеет сообщение из предыдущего модуля), мы также устанавливаем правильную реализацию службы для этого модуля.

(Например,: если Акула попадет в EatModule, мы установим для его поля eattingServiceInterface правильную реализацию для его типа.)

Практически, я ищу способ сохранить полиморфизм, но чтобыотделить поведение от состояния объекта, сохранив модель анемичного домена.

Преимущества, которые я вижу:

  • развязка бизнес-поведения в его собственных классах, возможность их простого изменения
  • полиморфизм и избегание сложной структуры "ifs" и грязного кода в этой сервис-ориентированной архитектуре и анемичной модели

Недостатки:

  • зависимости: домен зависит от сервиса и сервиса на домене

Особый контекст:

Мы разработали вид приложения сверху с нуля и скажеммы сделали 50% (серьезные усилия уже вложены).

Нам нужен объект «Животное» в каждом модуле, потому что в конце модуля мы отправляем «событие» с «новым состоянием»животный объект.

Я не доволен тем, как все происходит.Теперь, когда мы разрабатываем, мы просто ударили по большому количеству «если» в нашем коде.

У нас нет подклассов, потому что, когда я предложил создать их, мне ответили, что мы не должны создавать подкласс простопотому что у нас есть разные значения в одном поле, поле, которое можно использовать только один раз для выполнения оператора «if» в одном из модулей.

Теперь я считаю, что нам нужен полиморфизм, но нет никаких шансовотойти от SOA и модели анемичной области, поэтому я подумал над решением выше.

...