Как доменные объекты относятся друг к другу в Чистой Архитектуре - PullRequest
Новая
       37

Как доменные объекты относятся друг к другу в Чистой Архитектуре

0 голосов
/ 03 апреля 2020

Основано на определении сущности дяди Боба:

"Сущность - это чистый бизнес, а - ничто иное ."

Я хочу получить некоторые разъяснения относительно бизнес-логических отношений между сущностями. Давайте представим, что у нас есть 2 класса, и нам нужно реализовать связь между ними. Я вижу 3 варианта:

  1. Есть классы Client и Pet (Клиент один-ко-многим животным). Класс животных имеет идентификатор клиента 

    class Client {
  private _clientID: ClientID;

  public getID(): ClientID {
    return this._clientID;
  }
}


class Animal {
  private _animalID: AnimalID;
  private _ownerID: ClientID;

  public getID(): AnimalID {
    return this._animalID;
  }

  public getOwnerID(): ClientID {
    return this._ownerID;
  }
}

В этом случае мы знаем, кто является владельцем питомца по его идентификатору. Мы можем принять некоторые решения на основе существования ownerID.

Концерн № 1. Что нам следует делать, если нам необходимо принять какое-либо критическое деловое решение на основе поля связанной сущности?

Те же классы, но у класса Animal есть зависимость от клиента 

class Client {
  private _clientID: ClientID;

  public getID(): ClientID {
    return this._clientID;
  }
}


class Animal {
  private _animalID: AnimalID;
  private _owner: Client;

  public getID(): AnimalID {
    return this._animalID;
  }

  public getOwner(): Client {
    return this._owner;
  }
}

В этом случае мы знаем все о владельце.

Концерн № 2. в рамках этого подхода возможна ситуация, когда мы получим глубокую зависимость от сущности, подобную этой: 

A {
   B {
       C {
          ... and so on ...
       }
   }
}

Фактически, нам придется инициализировать каждую сущность из БД и внедрять их экземпляры в другие сущности.

У нас нет реляционных идентификаторов. Мы создаем такие методы, как «getPetsByClientId» (или наоборот) в репозиториях и координируем все вещи в случаях использования. 

class Client {
  private _clientID: ClientID;

  public getID(): ClientID {
    return this._clientID;
  }
}


class Animal {
  private _animalID: AnimalID;

  public getID(): AnimalID {
    return this._animalID;
  }
}

Проблема № 2: Мне кажется, мы теряем основную часть бизнес логи c здесь. Например, нам нужно принять какое-то решение в зависимости от того, есть ли у этого питомца владелец? (да, новое условие - теперь мы можем создать питомца без фактического владельца), и это решение является политикой высокого уровня, чистой бизнес-логикой c (опять же, мнимой). Таким образом, его место находится внутри сущности.

4 (дополнительно). Никакой панацеи. Каждый случай требует индивидуальной реализации. (<= самый грустный) </p>

1 Ответ

0 голосов
/ 13 апреля 2020

Объекты должны содержать и моделировать наиболее важные бизнес-правила. Если двунаправленная зависимость между двумя объектами домена является таким важным бизнес-правилом, это должно быть отражено в объектах.

Это может быть достигнуто с помощью идентификаторов для связи объектов или с прямыми ссылками на объекты. Для этого позже вы можете реализовать пользовательские операции равенства и сравнения для ваших сущностей в зависимости от поддержки вашим языком программирования.

...