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

Question

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

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

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

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

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

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

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

Answer 1

ну, вначале все выглядит так, но когда вы будете больше реорганизовывать свой код, вы получите некоторое поведение для класса вашей организации ...

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

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

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

Answer 2

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

Это все, что я хотел бы добавить к заппану и эпитке.

Answer 3

Это может быть просто анемией сейчас?

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

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

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

Answer 4

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