прежде чем засесть за шабл пр и DDD, не забывайте несколько важных моментов : 1)Как бы вы не пыхтели и не чесали репу громоздя абстракции, через несколько лет это все равно станет старым и непотребным говном. Что и кто бы вам не говорил. Откройте любой крутой проект, написанный 5 - 7- 10 лет назад, посмотрите на яз.конструкции, библиотеки и пр. обвесы. 2) Тема ШП, DDD в большой степени "греет" разного рода консультантов и нужна прежде всего им. 3) Современные тенденции постепенно смещаются к упрощению языков, минимализации абстракции и пр.
"юзер будет проникать везде" - в этом случае вы потеряете контест, потому что юзер - понятие пришедшее скорее из контекста безопасности приложения, а вот в контексте заказа товаров это уже будет "покупатель"
И да и нет, при такой архитектуре частенько придется проверять если именно юзер авторизирован совершать дейстие Х. А то что в каждом контектсе Юзер декорируется дополнительными полями и становиться Покупателем, Лидом, КонтрАгентом это тоже верно. Одно другому не мешает.
Интересный и полезный доклад! Спасибо! А подскажите кто-нибудь пожалуйста, как обычно имплементируется сущность User в контексте Пользователя приложения? Что обычно в себе реализует class User большинства проектов? Где User это просто пользователь сайта (админ, посетитель сайта, авторизованный посетитель сайта и тд), который может читать, писать, удалять, обновлять данные. Он что-то вообще должен делать или просто выступает в роли тупого хранилища value-object? Например, я так понимаю, для авторизации, регистрации пользователя обычно делается сервис-класс, который этого юзера регистрирует, авторизует и тд, так как User сам себя не авторизует и не регистрирует. Но что-то юзер должен делать? И, если знаете примеры которые мне могли бы быть полезны (желательно на Typescript/JS), дайте ссылку пожалуйста на Github.
А если HttpMapper будет посылать запрос на эндпойнт, к примеру, регистрации. Придется дополнить BaseMapper интерфейс методом register(по задумке автора) ?
"Почему мне не понравился Validator Symfony? Потому что невалидные состояния могли у меня проникнуть в логику." Так незачем использовать Validator Symfony для валидации Сущностей. Попытка создать Сущность с невалидным состоянием вполне спокойно может быть прервана с помощью выброса исключения доменного уровня внутри создаваемого объекта (т.к. Information Expert из GRASP).
@Artem Antonenko Symfony Forms и Symfony Validator отлично подходят, чтобы отвалидировать пользовательские данные ( внешний слой ). С доменным слоем инфраструктуру фрэймворка не рекомендовал бы завязывать. "Задача заключается в том, чтобы выявить и устранить невалидное поведение как можно раньше" - Ну, в таком случае, следует дублировать логику валидации в слое представления. Если все-таки задача "выявить и устранить невалидное поведение как можно раньше" не так важна, можно делегировать валидацию доменному слою. Если нужна детальная валидация всех данных, полученных от пользователя, в доменном слое следует использовать Notification Pattern ( как вариант ) martinfowler.com/eaaDev/Notification.html
@Artem Antonenko об application layer Эванс писал в своей книге. Вернон точно говорит об application services (которые находятся а app-layer) в своей книге. Причем и в контексте применения как слоевого стиля, так и гексагонального стиля (ports-adapters) архитектуры. Из того что помню, App layer управляет безопасностью, транзакциями и является прямым клиентом репозиториев. Единственным клиентом app-layer'a является слой UI (presentation).
@Artem Antonenko Также дополню ответ Давида Перманова, что благодаря Application Layer мы получаем возможность, представить Presentation Layer, как говорил Дядюшка Боб, в виде плагина. Т.е. один и тот же юзкейс можно исполнять из разных видов ui, без переписывания кода : REST API, SOAP, Web, CLI и прочее. Если же у Вас "Application находится в Infratructure Layer'е", с реюзабельностью юзкейса будут проблемы)
@@SLAv00Ik У Фаулера по моему 11 видов архитектур слоистых описано по версии разных инженеров. Такая абстракция как Application layer может быть избыточна в каких то системах.
@Artem Antonenko боюсь, что вы неправильно меня поняли. В любом случае, состояние агрегата как-то мутируется ( это связано с наличием поведения у rich domain объектов). Например, если администратор банит пользователя на форуме, его статус (пользователя) поменяется с "active" на "banned". Как, в подобных ситуациях, паттерн Builder поможет помочь соблюсти инварианты?
Простите за ссылку, но у вас описано очень тяжело... Хотя новое я узнал для себя. Лучший доклад, что я слышал для новичка тут: ua-cam.com/video/rjtbCyacJas/v-deo.html
Сейчас, в середине 2024 году, могу скзаать, что ддд как концепт устарел, народ переусердствует и создают просто 3 слоя крайней низкой связанностью, т.е. все идет к полному отделению. Есть те, кто видит ддд только на уровне модуля 2 уровня, а на первом все равно другой шаблон. И есть еще фрэймворки, а после слов, "я против фрэймоворков" сразу видно, что слушаем мы не разработчика, что очередной раз доказывает что ддд нам впихивают не разработчики, хотя Эванс как раз был разработчиком. Сюр.
@Artem Antonenko "Но в целом, использование паттерна Репозиторий как коллекции, в пхп (запрос/ответ подход) не имеют особого смысла" - можно более тезисно?
@@valigotech Репозиторий можно использовать и с ActiveRecord, нет проблем. Это патерны разных уровней. Repository патерн доменной модели, а ActiveReсord патерн персистинга в энергонезависимую БД.
прежде чем засесть за шабл пр и DDD, не забывайте несколько важных моментов : 1)Как бы вы не пыхтели и не чесали репу громоздя абстракции, через несколько лет это все равно станет старым и непотребным говном. Что и кто бы вам не говорил. Откройте любой крутой проект, написанный 5 - 7- 10 лет назад, посмотрите на яз.конструкции, библиотеки и пр. обвесы. 2) Тема ШП, DDD в большой степени "греет" разного рода консультантов и нужна прежде всего им. 3) Современные тенденции постепенно смещаются к упрощению языков, минимализации абстракции и пр.
все тлен, можно ничего не писать
Если не чайник можно начинать смотреть с 12:00 минуты )) Спасибо за доклад!
"юзер будет проникать везде" - в этом случае вы потеряете контест, потому что юзер - понятие пришедшее скорее из контекста безопасности приложения, а вот в контексте заказа товаров это уже будет "покупатель"
И да и нет, при такой архитектуре частенько придется проверять если именно юзер авторизирован совершать дейстие Х. А то что в каждом контектсе Юзер декорируется дополнительными полями и становиться Покупателем, Лидом, КонтрАгентом это тоже верно. Одно другому не мешает.
Спасибо за доклад! Не смог мимо ДДД пройти)
Спасибо за доклад и скелетон
Спасибо за доклад!
Используем примерно ту же имплементацию, что показал Артём. Пишем при этом на .Net Core
I realize it is pretty off topic but do anyone know of a good site to watch new series online?
@Trenton Turner I watch on flixzone. Just search on google for it :)
@Nathanael Diego definitely, have been using FlixZone for months myself =)
@Nathanael Diego thanks, I went there and it seems to work :) I appreciate it!
@Trenton Turner You are welcome =)
Спасибо за доклад
В ddd косвенно накладываются архитектурные границы где в главе - домен
Интересный и полезный доклад! Спасибо!
А подскажите кто-нибудь пожалуйста, как обычно имплементируется сущность User в контексте Пользователя приложения?
Что обычно в себе реализует class User большинства проектов? Где User это просто пользователь сайта (админ, посетитель сайта, авторизованный посетитель сайта и тд), который может читать, писать, удалять, обновлять данные.
Он что-то вообще должен делать или просто выступает в роли тупого хранилища value-object?
Например, я так понимаю, для авторизации, регистрации пользователя обычно делается сервис-класс, который этого юзера регистрирует, авторизует и тд, так как User сам себя не авторизует и не регистрирует.
Но что-то юзер должен делать?
И, если знаете примеры которые мне могли бы быть полезны (желательно на Typescript/JS), дайте ссылку пожалуйста на Github.
топ доклад
Круто, спасибо.
Интересно слушать
Отлично подано! Спасибо!
А если HttpMapper будет посылать запрос на эндпойнт, к примеру, регистрации. Придется дополнить BaseMapper интерфейс методом register(по задумке автора) ?
"Почему мне не понравился Validator Symfony? Потому что невалидные состояния могли у меня проникнуть в логику."
Так незачем использовать Validator Symfony для валидации Сущностей. Попытка создать Сущность с невалидным состоянием вполне спокойно может быть прервана с помощью выброса исключения доменного уровня внутри создаваемого объекта (т.к. Information Expert из GRASP).
@Artem Antonenko
Symfony Forms и Symfony Validator отлично подходят, чтобы отвалидировать пользовательские данные ( внешний слой ). С доменным слоем инфраструктуру фрэймворка не рекомендовал бы завязывать.
"Задача заключается в том, чтобы выявить и устранить невалидное поведение как можно раньше" - Ну, в таком случае, следует дублировать логику валидации в слое представления. Если все-таки задача "выявить и устранить невалидное поведение как можно раньше" не так важна, можно делегировать валидацию доменному слою. Если нужна детальная валидация всех данных, полученных от пользователя, в доменном слое следует использовать Notification Pattern ( как вариант ) martinfowler.com/eaaDev/Notification.html
Все таки не-анимичные модели лично для меня это ключевое в ДДД, а тут только анимичные :( но все равно спасибо за доклад
В "Слоевой" архитектуре где-то потерялся Application Layer.
Все, услышал: "Application находится в Infratructure Layer'е".
И как же он туда попал, интересно?
@Artem Antonenko об application layer Эванс писал в своей книге.
Вернон точно говорит об application services (которые находятся а app-layer) в своей книге. Причем и в контексте применения как слоевого стиля, так и гексагонального стиля (ports-adapters) архитектуры.
Из того что помню, App layer управляет безопасностью, транзакциями и является прямым клиентом репозиториев. Единственным клиентом app-layer'a является слой UI (presentation).
@Artem Antonenko Также дополню ответ Давида Перманова, что благодаря Application Layer мы получаем возможность, представить Presentation Layer, как говорил Дядюшка Боб, в виде плагина. Т.е. один и тот же юзкейс можно исполнять из разных видов ui, без переписывания кода : REST API, SOAP, Web, CLI и прочее. Если же у Вас "Application находится в Infratructure Layer'е", с реюзабельностью юзкейса будут проблемы)
@@SLAv00Ik У Фаулера по моему 11 видов архитектур слоистых описано по версии разных инженеров. Такая абстракция как Application layer может быть избыточна в каких то системах.
"За инвариантность анемичной модели отвечает Builder". А что в ситуации, когда пытаемся мутировать состояние уже созданного объекта?
@Artem Antonenko боюсь, что вы неправильно меня поняли. В любом случае, состояние агрегата как-то мутируется ( это связано с наличием поведения у rich domain объектов). Например, если администратор банит пользователя на форуме, его статус (пользователя) поменяется с "active" на "banned". Как, в подобных ситуациях, паттерн Builder поможет помочь соблюсти инварианты?
Было всё понятно до момента пока не начали задавать вопросы ....))))
Простите за ссылку, но у вас описано очень тяжело... Хотя новое я узнал для себя. Лучший доклад, что я слышал для новичка тут: ua-cam.com/video/rjtbCyacJas/v-deo.html
Сейчас, в середине 2024 году, могу скзаать, что ддд как концепт устарел, народ переусердствует и создают просто 3 слоя крайней низкой связанностью, т.е. все идет к полному отделению. Есть те, кто видит ддд только на уровне модуля 2 уровня, а на первом все равно другой шаблон. И есть еще фрэймворки, а после слов, "я против фрэймоворков" сразу видно, что слушаем мы не разработчика, что очередной раз доказывает что ддд нам впихивают не разработчики, хотя Эванс как раз был разработчиком. Сюр.
С каких пор DataMapper является альтернативой Repository?
@Artem Antonenko ua-cam.com/video/_CK5Kag7enw/v-deo.html
@@sdfzghjk Я думаю, active record имелся в виду. Типа active record vs repository. Артем даже сказал "active record" разок.
@Artem Antonenko "Но в целом, использование паттерна Репозиторий как коллекции, в пхп (запрос/ответ подход) не имеют особого смысла" - можно более тезисно?
@@valigotech Репозиторий можно использовать и с ActiveRecord, нет проблем. Это патерны разных уровней. Repository патерн доменной модели, а ActiveReсord патерн персистинга в энергонезависимую БД.
Так себе и представил девелопера: "Бизнес, чет вы херню говорите - идите нафиг". А зп он сам будет себе платить?
Ептаюмать, столько слов которые можно было просто на русском сказать
У меня аж смузи из монитора закапало
писиар)))
Размазоно все, не интересно
Какой я хороший поработайте со мной а иначе вы все делаете не правильно - ещё очередная ddd барыга без достаточного опыта
Скинь Ютуб с опытным небарыгой ddd
Слава Украине!