тоже нужно разобраться )))

в данном контексте модель не имеет никакого отношения к предметной области

Adel выше привел пример, который сразу поставил мои мысли на место

File, HttpRequest, MailMessage и т.д. - не имеют отношения к предметной области, но являются объектами инфраструктурного уровня

в данном контексте модель не имеет никакого отношения к предметной области

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

получаются, они не являются моделями?

получаются, они не являются моделями?

"модели" - это общее довольно слово. Модель данных, модель предметной области, модели описывающая работу конкретной сущности из предметной области. модель, описывающая работу с инфраструктурой. Общее и бесполезное слово.

Связан с Email, верно: служба на прикладном уровне дёргает службу на инфраструктурном уровне, чтобы отправить письмо. Объект "письмо" не является объектом разрабатываемой предметной области.

Тут, наверное, лучше вместо "модель" использовать более конкретное - "сущность"

Лол, мне кажется сущность в тыщу раз менее конкретно чем модель даже

Сущность сущность сущность

Мы с тобой тоже сущности

Я привел более простой пример с "письмом". На самом деле у меня пример чуть сложнее: реестр задач, которые выполняются внешними приложениями. Внешние приложения получают эти задачи через брокер. "Задача" - это объект предметной области, а вот "реестр задач" - нет.

Сущность сущность сущность

Тошнит от этого слова иногда если честно

Мы с тобой тоже сущности

)))) смотря в каком контекте )) некоторые из нас - просто value-object

объект email является vo, если просто его создать и отправить?

объект email является vo, если просто его создать и отправить?

да

подробнее читаем про data abstraction

спасибо ) прочту

возможно. мой пример с email был для простоты понимания вопроса.

если надо хранить все отправленные сообщения, то entity

но тогда, наверное, он становится объектом предметной области?

если надо хранить все отправленные сообщения, то entity

тогда у них обычно появляется id. что намекает

если надо хранить все отправленные сообщения, то entity

это не так работает

угу

а как?

entity это не про "хранить" а про идентификацию. Когда тебе важно что два имейла у которых содержимое идентично это разные имейлы - надо вводить им какой-то идентификатор и соответственно можно говорить о сущности. Если тебе это не важно - то это VO.

ну то есть тот факт что хранить в базе тебе удобно то что имеет идентификатор - это скорее следствие а не причина

это ясно. я думал "не так работает" - это речь о разделении на слои

ну и да - VO не имеют жизненного цикла - еще одно ограничение

это ясно. я думал "не так работает" - это речь о разделении на слои

слои это ложь)

))))

на практике не бывает? )

я думал не так работает, это то, что необязательно чтото с id становится часть домена. у нас могут быть всякие таски в очереди, каждая с id. Но к домену они отношения не имеют.

Я сейчас хочу понять всего один маленький момент, который, видимо, я упустил. Вне предметной области могут быть точно такие же entity и vo, которые работают точно так же, но просто не относятся к самому предмету. Верно? То есть не важно, относится к предмету entity или не относится - он все равно entity, не важно на каком слое (которых не бывает) он находится.

на практике не бывает? )

нет, проблема со слоями в том что это второстепенная вещь которая будет проявляться так или иначе если ты разделением ответственности занимаешься. Но они, повторюсь, второстепенны. То есть ты когда проектируешь про слои не думай, думай о разделении на зоны ответственности. Слои никак не должны влиять ни на структуру проекта, ни на что быто нибыло еще. Это мнимая штука. Слои полезны но намного важнее просто разделять ответственность. Причем не только горизонтально но и вертикально (bounded context). Последнее оч важно если хочется большие проекты нормально делать

Я сейчас хочу понять всего один маленький момент, который, видимо, я упустил. Вне предметной области могут быть точно такие же entity и vo, которые работают точно так же, но просто не относятся к самому предмету. Верно? То есть не важно, относится к предмету entity или не относится - он все равно entity, не важно на каком слое (которых не бывает) он находится.

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

entity это не про "хранить" а про идентификацию. Когда тебе важно что два имейла у которых содержимое идентично это разные имейлы - надо вводить им какой-то идентификатор и соответственно можно говорить о сущности. Если тебе это не важно - то это VO.

А если тебе важна идентификация(например эвенты), но при этом при агрегации эвентов 2 последовательных одинаковых по содержимому эвента результируют в один эвент, то что это такое?

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

Достаточно распространённая практика когда речь идёт о эвентах вроде лайка поста в соц сети

А если тебе важна идентификация(например эвенты), но при этом при агрегации эвентов 2 последовательных одинаковых по содержимому эвента результируют в один эвент, то что это такое?

не стой, ивенты это VO

Ну у них есть идентификация

у них нет жизненного цикла и в целом два ивента которые ссылаются на одно и то же события - являются одним и тем же

Достаточно распространённая практика когда речь идёт о эвентах вроде лайка поста в соц сети

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

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

ну то есть это нормальный подход? опять же если очень упрощенно, отказаться от контроля за консистентностью на уровне СУБД, но получить плюсы от микросвервисной архитектуры аля масштабируемость и прочее? Или я что-то не беру в расчет?

у них нет жизненного цикла и в целом два ивента которые ссылаются на одно и то же события - являются одним и тем же

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

Жизни-то у них нет, что верно подмечено, но без идентификатора им никак чтобы всё правильно работало

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

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

Жизни-то у них нет, что верно подмечено, но без идентификатора им никак чтобы всё правильно работало

им не нужен идентификатор ивента (потому что это будет два разных ивента в описанном тобой случае) - им нужно что бы ивент хранил идентификатор кто и что лайкнул. То есть это VO

ну то есть это нормальный подход? опять же если очень упрощенно, отказаться от контроля за консистентностью на уровне СУБД, но получить плюсы от микросвервисной архитектуры аля масштабируемость и прочее? Или я что-то не беру в расчет?

товары в базе удаляться просто не должны. И заказы. И вообще удаление чего либо это плохая идея. Если надо - можешь сделать архивацию и ревизионирование.

VO не имеет жизненного цикла - интересно. Я всегда думал, что объект заканчивает жизненный цикл, когда отрабатывает деструктор (либо скрипт заканчивает свою работу)

Но а как ты без идентификатора отдебажишь нормально?) У них же по сути была зафиксирована жизнь, которая важна в твоём контексте. Сам факт того что этот эвент предшествовал предыдущему максимально критично

По мне просто определение VO это только иммутабельные объекты

VO не имеет жизненного цикла - интересно. Я всегда думал, что объект заканчивает жизненный цикл, когда отрабатывает деструктор (либо скрипт заканчивает свою работу)

ты когда в последний раз деструктор делал? Деструктор нужен для того что бы памяти высвободить. За последние 5 лет я не помню что бы мне приходилось деструкторы писать. Деструкторы удобны там где есть ручное управление память. Причем в PHP какое-то время оно с багами было. А в Hack вообще хотят их выпилить что бы оптимизировать управление памятью

Любые мутабельные уже VO по своей сути называться не могут

ты когда в последний раз деструктор делал? Деструктор нужен для того что бы памяти высвободить. За последние 5 лет я не помню что бы мне приходилось деструкторы писать. Деструкторы удобны там где есть ручное управление память. Причем в PHP какое-то время оно с багами было. А в Hack вообще хотят их выпилить что бы оптимизировать управление памятью

ну вот года 3 назад :D

По мне просто определение VO это только иммутабельные объекты

А определение с идентификатором не очень внятное

Но а как ты без идентификатора отдебажишь нормально?) У них же по сути была зафиксирована жизнь, которая важна в твоём контексте. Сам факт того что этот эвент предшествовал предыдущему максимально критично

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

По мне просто определение VO это только иммутабельные объекты

имутабельные => отсутствует жизненный цикл и идентификация осуществляется по значению. Сущности тоже могут быть имутабельными . Деньги для тебя и меня - VO. Деньги для монетного двора - сущность

Почему при иммутабельности идентификация не может осуществляться по айди? Твои эмейлы могут иммутабельны

bool это тоже VO. Какой там жизненный цикл у него?

Почему при иммутабельности идентификация не может осуществляться по айди? Твои эмейлы могут иммутабельны

почему не может? может) а есть еще жирная тема про естественные и сурагатные идентификаторы)

bool это тоже VO. Какой там жизненный цикл у него?

bool это примитив.

но в целом можно говорить о нем как о VO. просто это тупо)

но позволяет прояснить некоторые моменты

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

Ну вот ты сам попробуй напиши брокер который хранит все эвенты и предоставляет возможность читать откуда угодно. Получится что тебе придётся идентифицировать иммутабельные данные.

Энтити может быть иммутабельной?

Энтити может быть иммутабельной?

Да вполне

Мое мнение просто что если все данные делать иммутабельными, то черта между энтити и во почти отсутствует

Я привел пример - конкретная купюра никогда не поменяется

Ничто никогда не поменяется по-хорошему, твой чек в магазине никогда не поменяется даже если продавец ошибся, он выпишет новый чек

То что было в конкретный отрезок времени не изменить

Мое мнение просто что если все данные делать иммутабельными, то черта между энтити и во почти отсутствует

все равно энтити могут фетчиться по id. VO - нет

Если ты делаешь заказ, но товара нет на месте, сам факт того что ты сделал заказ уже был и его не отменить, ты делаешь новый заказ, а не меняешь старый

Тоже самое и с монетным двором в общем-то

Ага, зачеркнул, перечеркнул всё, наделал ошибок из-за того что надо пересчитывать налог...

И всё это вместо того чтобы с чистого листа проследовать четкой инструкции которую только что применял, и не стоит забывать что это в 2018 году абсолютно бесплатно))

Всем привет

Привет

А если тебе важна идентификация(например эвенты), но при этом при агрегации эвентов 2 последовательных одинаковых по содержимому эвента результируют в один эвент, то что это такое?

Это разные контексты, в одном контексте это entity, в другом это vo