SF
а если у тебя несколько сущностей каждый из которых ссылается на один и тот же identity
Ну наверное пример неудачный, ибо вокруг Order дб как минимум всякие даты и проч - вот сущность (или VO).
Size: a a a
2021 February 15
SP
Ну наверное пример неудачный, ибо вокруг Order дб как минимум всякие даты и проч - вот сущность (или VO).
в этом опасность сущностей. Ты слишком быстро делать выводы начинаешь. Стоит разобраться как эти даты используются, в каком контексте и т.д. и вдруг выйдет что "вот эти даты это shipping detail" а вот те это OrderInfo
k
Ну наверное пример неудачный, ибо вокруг Order дб как минимум всякие даты и проч - вот сущность (или VO).
вокруг Order есть процессы - процесс доставки, процесс покупки, процесс формирования цены что-то ещё
SP
SP
вот на тему заказов карзин и прочих заблуждений
SP
повторюсь - все это становится куда интереснее когда тебя начинают заботить вопросы bounded context и разные виды поддоменов (какие из них кор, какие суппортинг, какие generic).
SP
а то начинаются своих эвансов, сделают у себя в корне проекта CoreDomain и скажут что "это все домен" и будут туда юзеров и его креды складывать
SF
а то начинаются своих эвансов, сделают у себя в корне проекта CoreDomain и скажут что "это все домен" и будут туда юзеров и его креды складывать
А разве домен не должен быть легкопереносимым?
SP
А разве домен не должен быть легкопереносимым?
а что это значит?
SP
Я к тому что оч часто люди CoreDomain модуль делают и не понимают что такое core domain (+ какие еще домены бывают)
SP
что до "переносимости" - попробуй перенести домен большого продукта с php на kotlin :)
"переносимость" и прочее может быть приятным побочным эффектом но смысл в том что бы оградить влияние "технократических аспектов" твоей системы на модель предметной области.
"переносимость" и прочее может быть приятным побочным эффектом но смысл в том что бы оградить влияние "технократических аспектов" твоей системы на модель предметной области.
SP
DDD вообще не про код. То есть тупой круд в дерганьем SQL в контроллерах тоже можно делать по DDD если у тебя домен достаточно простой.
a
что до "переносимости" - попробуй перенести домен большого продукта с php на kotlin :)
"переносимость" и прочее может быть приятным побочным эффектом но смысл в том что бы оградить влияние "технократических аспектов" твоей системы на модель предметной области.
"переносимость" и прочее может быть приятным побочным эффектом но смысл в том что бы оградить влияние "технократических аспектов" твоей системы на модель предметной области.
про "попробуй" интересная реплика
a
мне кажется, или доменный код - один из самых удобных случаев для транспайла из одного языка в другой?
(минимум сторонних утилит, сайд эффектов и неочевидного кода)
(минимум сторонних утилит, сайд эффектов и неочевидного кода)
SP
atcq (Алексей)
мне кажется, или доменный код - один из самых удобных случаев для транспайла из одного языка в другой?
(минимум сторонних утилит, сайд эффектов и неочевидного кода)
(минимум сторонних утилит, сайд эффектов и неочевидного кода)
в целом да, и ты упрешься в то что доменная модель это обычно 10% кода.
SP
и толку от его переносимости в целом не оч много
SP
ну то есть не надо думать что изоляция доменной модели делается для "переносимости". Изоляция нужна сама по себе. low coupling/high cohesion и вот это все.
DT
DDD вообще не про код. То есть тупой круд в дерганьем SQL в контроллерах тоже можно делать по DDD если у тебя домен достаточно простой.
Я думал ддд про тройку бизнес - разработка - код. Что эти трое должны иметь один и тот же язык, единое понимание того что происходит и как.
А дёрганье sql в контроллерах не очень соответствует этой модели в том плане, что содержит язык который понимают последние два, но абсолютно не понимает (и не должен) первый
А дёрганье sql в контроллерах не очень соответствует этой модели в том плане, что содержит язык который понимают последние два, но абсолютно не понимает (и не должен) первый
DT
Уди помоему говорил, что если технические ограничения влияют на работу бизнеса, то они становятся частью домена
DT
*ограничения или особенности