Работа с анемичной доменной моделью

Question

Я пытался отделить свой DAL от своего бизнес-уровня, и при этом я решил отказаться от любого подхода ActiveRecord и перейти на подход DataMapper.Другими словами, объекты моего домена сами не позаботились бы о сохранении.Поступая таким образом, я, похоже, посягаю на анти-паттерн "анемичной доменной модели".Например, одной из сущностей в моей программе является Организация.

Организация представлена примерно так:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

Таким образом, по сути, эта организация не делает ничего, кроме как выполняет роль "мешка" (как говорит Мартин Фаулер) для некоторых данных.В мире PHP это не что иное, как прославленный массив.С этим связано нулевое поведение.

И поведение в программе, я придерживался класса "уровень обслуживания", такого как OrganizationService, который в основном служит посредником между этими объектами и DAL.

Помимо потенциальных проблем с масштабированием с PHP (у меня есть другие причины, по которым я настаиваю на "упаковывании" моих данных в эти объекты), полностью ли этот подход исключен?

Как вы справляетесь со своими предметными моделями в таких ситуациях?Возможно, организация вообще не является частью моего домена?

Answer 1

ну, поначалу так кажется, но когда вы еще раз проведете рефакторинг своего кода, вы получите некоторое поведение для вашего класса organization...

один из примеров, о котором я мог бы сейчас подумать, - если у вас есть люди (сотрудники), вы можете захотеть связать их с организацией.итак, у вас может быть метод AssociateEmployee(User employee) это может найти свое место в вашем классе организации.

Или вы можете изменить местоположение компании, вместо того чтобы устанавливать такие параметры, как адрес, город, штат в три этапа, вы могли бы добавить ChangeLocation(Street, City, State) способ..

Просто идите шаг за шагом, и когда вы столкнетесь с каким-либо кодом на вашем уровне BL / service, который, по-видимому, должен принадлежать домену, переместите его вниз, в домен.Если вы читаете Фаулера, вы получите его очень скоро, когда увидите в своем коде.

Answer 2

Может быть, сейчас у него просто анемия?

Например, однажды я разрабатывал сайт для регистрации на собрания / конференции.Все началось всего с одной встречи.

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

Поэтому я думаю, важно иметь в виду, что домены меняются со временем, и ваша модель может в конечном итоге подвергнуться рефакторингу, поэтому, даже если вы можете подумать, что она анемична, она может быть просто немного слишком дальновидной (например, ваш класс organization начнет получать некоторые настройки, правила или предпочтения или что-то в этом роде).

Answer 3

Вы также можете подумать о том, что если у вас не так много бизнес-правил или домен просто не такой сложный, то DDD может оказаться для вас слишком накладным.DDD - отличное решение для больших, сложных доменов, но требует больших накладных расходов и сложности, если вы просто вводите и выводите данные.DDD сложнее спроектировать, и он по своей сути усложняет задачу, поэтому, чтобы оправдать это, сложность проблемной области должна перевешивать это.

Это все, что я бы добавил к zappan и epitka.

Answer 4

Ваша сущность не является анемичной, потому что вы берете на себя ответственность, которой не должно быть с самого начала.Сохранение и извлечение объектов - это ответственность репозиториев.На самом деле ваше поведение должно быть в ваших сущностях, а не на уровне сервиса.Но объяснение того, что куда ведет, выходит далеко за рамки простого ответа.DDD Эрика Эванса - хорошая отправная точка.