Артём Антоненко «Domain Driven Design» | CODEiD (11.08.2018)
Vložit
- čas přidán 21. 08. 2018
- Артём Антоненко, Application architect in XLNTech выступил на конференции CODEiD - PHP Odessa Conf #4 с темой «Domain Driven Design».
«Очень много разработчиков, выбравших PHP основным языком программирования, получили свои знания по архитектуре из инструкций для фреймворков. Немногие обратились к источникам, которые написаны для (с помощью) Java, C++ и других языков. Язык PHP уже давно перестал быть уделом домохозяек и перешел в инструменты для разработки enterprise приложений.
Но как писать такой код, который будет понятен и легко расширяем через год, два и более?
Как подготовить монолит к разделению на микросервисы?
Как выстроить эффективное взаимодействие со stakeholders?
На эти вопросы отвечает предметно-ориентироанние программирование.»
Презентация: bit.ly/2V2o32L
CODEiD - это всеукраинское сообщество PHP-разработчиков. Наша цель - создать сильное сообщество всех, кто увлечен PHP-разработкой, и принимать в нашем уютном приморском городе коллег со всей Украины и мира.
Подписывайтесь на наши страницы:
Telegram: t.me/codeidua
Facebook: / codeidua
Twitter: / codeidua
Instagram: / codeidua - Věda a technologie
прежде чем засесть за шабл пр и 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 косвенно накладываются архитектурные границы где в главе - домен
Круто, спасибо.
А если HttpMapper будет посылать запрос на эндпойнт, к примеру, регистрации. Придется дополнить BaseMapper интерфейс методом register(по задумке автора) ?
Интересно слушать
топ доклад
Интересный и полезный доклад! Спасибо!
А подскажите кто-нибудь пожалуйста, как обычно имплементируется сущность User в контексте Пользователя приложения?
Что обычно в себе реализует class User большинства проектов? Где User это просто пользователь сайта (админ, посетитель сайта, авторизованный посетитель сайта и тд), который может читать, писать, удалять, обновлять данные.
Он что-то вообще должен делать или просто выступает в роли тупого хранилища value-object?
Например, я так понимаю, для авторизации, регистрации пользователя обычно делается сервис-класс, который этого юзера регистрирует, авторизует и тд, так как User сам себя не авторизует и не регистрирует.
Но что-то юзер должен делать?
И, если знаете примеры которые мне могли бы быть полезны (желательно на Typescript/JS), дайте ссылку пожалуйста на Github.
"Почему мне не понравился Validator Symfony? Потому что невалидные состояния могли у меня проникнуть в логику."
Так незачем использовать Validator Symfony для валидации Сущностей. Попытка создать Сущность с невалидным состоянием вполне спокойно может быть прервана с помощью выброса исключения доменного уровня внутри создаваемого объекта (т.к. Information Expert из GRASP).
@Artem Antonenko
Symfony Forms и Symfony Validator отлично подходят, чтобы отвалидировать пользовательские данные ( внешний слой ). С доменным слоем инфраструктуру фрэймворка не рекомендовал бы завязывать.
"Задача заключается в том, чтобы выявить и устранить невалидное поведение как можно раньше" - Ну, в таком случае, следует дублировать логику валидации в слое представления. Если все-таки задача "выявить и устранить невалидное поведение как можно раньше" не так важна, можно делегировать валидацию доменному слою. Если нужна детальная валидация всех данных, полученных от пользователя, в доменном слое следует использовать Notification Pattern ( как вариант ) martinfowler.com/eaaDev/Notification.html
Все таки не-анимичные модели лично для меня это ключевое в ДДД, а тут только анимичные :( но все равно спасибо за доклад
"За инвариантность анемичной модели отвечает Builder". А что в ситуации, когда пытаемся мутировать состояние уже созданного объекта?
@Artem Antonenko боюсь, что вы неправильно меня поняли. В любом случае, состояние агрегата как-то мутируется ( это связано с наличием поведения у rich domain объектов). Например, если администратор банит пользователя на форуме, его статус (пользователя) поменяется с "active" на "banned". Как, в подобных ситуациях, паттерн Builder поможет помочь соблюсти инварианты?
Было всё понятно до момента пока не начали задавать вопросы ....))))
В "Слоевой" архитектуре где-то потерялся 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 может быть избыточна в каких то системах.
Простите за ссылку, но у вас описано очень тяжело... Хотя новое я узнал для себя. Лучший доклад, что я слышал для новичка тут: czcams.com/video/rjtbCyacJas/video.html
С каких пор DataMapper является альтернативой Repository?
@Artem Antonenko czcams.com/video/_CK5Kag7enw/video.html
@@sdfzghjk Я думаю, active record имелся в виду. Типа active record vs repository. Артем даже сказал "active record" разок.
@Artem Antonenko "Но в целом, использование паттерна Репозиторий как коллекции, в пхп (запрос/ответ подход) не имеют особого смысла" - можно более тезисно?
@@valentjedi Репозиторий можно использовать и с ActiveRecord, нет проблем. Это патерны разных уровней. Repository патерн доменной модели, а ActiveReсord патерн персистинга в энергонезависимую БД.
Так себе и представил девелопера: "Бизнес, чет вы херню говорите - идите нафиг". А зп он сам будет себе платить?
писиар)))
Ептаюмать, столько слов которые можно было просто на русском сказать
У меня аж смузи из монитора закапало
Какой я хороший поработайте со мной а иначе вы все делаете не правильно - ещё очередная ddd барыга без достаточного опыта
Скинь Ютуб с опытным небарыгой ddd
Размазоно все, не интересно
Слава Украине!