data-mapper или active-record

[Adelf]

Почти все операции агрегата Проект будут doSomethingWithIssue(issueId, params).

По мне это странно. Да. У Фаулера, видимо не та зависть. Но тут этот агрегат кажется просто лишней прослойкой. Он просто будет искать issue и передавать ему команду.

 

[Вурдалак]

По мне это странно. Да. У Фаулера, видимо не та зависть. Но тут этот агрегат кажется просто лишней прослойкой. Он просто будет искать issue и передавать ему команду.

Напомню, что мы рассуждаем о гипотетическом примере, в реальности, конечно же, я был бы против такого aggregate root. Просто причины разные.

Почти все операции агрегата Проект будут doSomethingWithIssue(issueId, params)

«Чуть-чуть не считается». Как же ты поступишь с LinkIssues, UnlinkIssues и прочими командами, которые затрагивают несколько issues одновременно и/или не относятся ни к одной из них конкретно?

Но тут можно посмотреть на проблему под другим углом: что если Issue в Project и Issue, о котором говоришь ты (где нужно поменять описание, сменить исполнителя и прочее) — это разные объекты?

 

[Adelf]

Но тут можно посмотреть на проблему под другим углом: что если Issue в Project и Issue, о котором говоришь ты (где нужно поменять описание, сменить исполнителя и прочее) — это разные объекты?

Вероятно так оно и будет если идти true-DDD way. Но там же возникает как раз объявленная тобою техническая проблема. Как сделать это идеально правильно?

 

[WMix]

@Adelf, я думаю это правильный ответ.

$father = $mapper->father($person);

те. mapper знает о relation а entity нет.

тогда и proxy не нужны

единственное что меня смущает, mapper жирноватый становится.

 

[Adelf]

@WMix, в твоем случае, если мы говорим о медицине и генетических заболеваниях, Person будет иметь свойство... в котором будут аккумулирована информация о его предках. в нужном виде. там не будет имен людей или чего-то там. Только необходимая инфа связанная с наследственными заболеваниями. И маппер будет вытаскивать это все сразу. вместе с другой инфой о Person.

 

[WMix]

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

это не аттрибут человека "его отец". и я уже даже склоняюсь к тому что item у order тоже отдельная часть сущности, иначе получается либо жирная сущность со всякими проксями (своего рода AR которая может сама себя загрузить), либо сложный mapping загрузи (то, это и еще вон те 2 штуки и всунь по местам).

но логика сервиса становится сложнее, причем явно сложнее

 

[Вурдалак]

Как сделать это идеально правильно?

Programming is an art of tradeoffs (кто-то в Интернете). Боюсь, что никак.

это не аттрибут человека "его отец"

Верно. Потому что тебе нужен не его отец, а его наследственные признаки, которые уже часть самого ребёнка.

 

[WMix]

наследственные признаки или лучше сказать болезни, да (те уже нечто просчитанное - некий SET(1,42,15,222...) ), при этом это тоже может быть отдельной collection сущности "Болезнь"
болезни предков нет (их еще предстоит посчитать)

 

[Вурдалак]

наследственные признаки или лучше сказать болезни, да (те уже нечто просчитанное - некий SET(1,42,15,222...) ),
болезни предков нет (их еще предстоит посчитать)

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

UPD: Хотя я тебя не понял. Наследственные признаки/болезни ты говоришь есть, тогда в чём проблема и зачем нужны родители?

 

[WMix]

филосовствуем я согласен, я немного о другом, о том чтоб разделить на разные сущности и работать отдельно.. но если "наследственные заболевания" это текстовое поле, типа примичание, нехай лежит пока у пациента... ну те в данном случае не пример интересен а сам подход оставлять только простые линейные сущности.
никаких items у order

 

[Adelf]

@WMix, тебя вероятно не устраивает что это вся наследственная инфа каждый раз для Person будет вытаскиваться из базы.
Надо понимать, что скорее всего в мире DDD будет какойнибудь RegularPatient у которого будет имя, фамилия. И его мы сможем...регистрировать в палату на полежать. И другие операции не связанные с диагностикой.
А еще будет PatientForDiagnose - у него тоже будут имя, но никаких знаний о палатах .. или чего еще. НО будет наследственная инфа, которая будет доставаться сразу. Частично при доставании из базы этих сущностей будут юзаться одни и те же таблицы. Частично разные.

 

[WMix]

наследственная инфа каждый раз для Person будет вытаскиваться из базы.

наоборот, только когда в сервисе попрошу

RegularPatient у которого будет имя, фамилия

год рождения, вес, номер страховки.. но не посещения, история болезни и тд

 

[WMix]

PatientForDiagnose вобще не понял.. одно дело нарисовать, другое дело нажали на кнопку "сделай тото" и в этот момент нужно только "это" а возможные изменения "другого" можно на событие подвесить