Сервисный слой и контроллеры, мысли
7 апреля 2017
Вышла ещё одна статья Дмитрия Елисеева о сервисном слое, репозиториях и использование всего этого с примерами на Yii.
Статья ближе к не идеальной реальности, чем предыдущая. Некоторые подходы вроде сервисов полезно применять даже в тех случах, когда в проекте нет никакого DDD.
Сервисы получаются при рефакторинге кода контроллеров сами собой, с ними легче тестировать и код вроде «получить данные из POST» не мешается при чтении.
Кстати, в одном из коммерческих проектов я сделал черновой вариант DDD-слоя. После ревью ветку было рекомендовано удалить — разрабатывать надо быстро, на переписывание время будет, если что. В сущностях, контекстах, репозиториях и всём таком кроме меня никто не разберётся нормально. Что важно. Не знакомой с DDD команде надо выдавать результат, а не ступориться на непривычной организации приложения. Отмечу, что это не повод не учиться.
С репозиториями уже не так всё просто и применимо. Репозитории должны оперировать чистыми объектами с данными, DTO. Ради этого приходится отказаться от ActiveRecord, что не всегда оправдано. Можно сделать как пишет Эльвира Шеина. Формально это не правильно, но плюсы также будут.
К сожалению, на вопросы к предыдущей статье ответов в свежей не было, но зато в комментариях как раз эти вопросы всплыли, что указывает на их важность. Ответы на вопросы предыдущей заметки были раскрыты в той самой статье, о которой были мысли.
Если вы еще не были в разделе по архитектуре на форуме yiiframework.ru, заходите. Там много интересных обсуждений.
Комментарии RSS по email OK
Опечатка - не DTO, а Сущностями (Entities)
Ответами дополнил как раз предыдущую.
Я с DDD знаком, для меня только один вопрос остался - какой способ сохранения сущностей агрегата, хранящихся в отдельных связанных таблицах, предложит/применит Дмитрий. Будет ли он полностью их перезаписывать при обновлении, проксировать агрегат и коллекцию связанных сущностей и сохранять только то, что было изменено или добавлено или предложит сохранять сущности по отдельности в сервисе внутри транзакции.
Дмитрий Елисеев, перечитал. Всё нашёл. Статья стала ещё лучше.
Похоже с каждым выпуском нового ПХП колесо сансары проворачивается, и пхп-шники возвращаются к разбитым корытам :) Случайно увидел заметку и вспомнил про первую yiiconf в Киеве и свой доклад про слоистую архитектуру и ДДД. Было это 5 лет назад, но сообщество на том же уровне.
Перечитал эту предыдущую статью, про которые идет речь, и просто подохерел, как простые и интуитивные вещи можно объяснять с таким изъебом, уж извините за маты.
ДДД это крайне простая штука, и я беру зеленого студента, 3 часа ему рассказываю про предметку, и через неделю он вовсю пишет код, причем код хороший! А тут "В сущностях, контекстах, репозиториях и всём таком кроме меня никто не разберётся нормально" - ну значит фигни понаписал автор, пытаясь применить все богатство ДДД там где это нафиг никому не надо. Не делайте так!
А вообще ООП в программировании не несет никакой пользы для конечного результата, кроме извращенного удовольствия для программиста.
Алексей, а вы можете простым и понятным языком написать про DDD, как для студента? Или можно где-то почитать ваши заметки. Как можно найти ваш доклад?
Алексей, люди об этом книги пишут, а вы за 3 часа... Не сходится что-то. Может у вас DDD какой-то другой или книги Вернона и Эванса тоже "много воды" и "сложно о простом"?
Алексей, мне показалось, что ваш доклад о микросервисах и SOA, а не DDD. Вы немного путаете аббревиатуры.
Есть известная всем книга, там так и написано, просто, понятно и для студентов. Зачем пересказывать то?
Это потому что я не книгу ему пересказываю (которая кстати за 3 часа и читается), а предметку проекта с которым ему прийдется работать. На это час уходит. Потом 2 часа показывается как на эту предметку ложится код проекта. Еще 15 минут какие есть нюансы мапинга ValueObjects в базу (если такие есть). И все, ребят. Больше то рассказывать не про что.
Давайте про Yii и DDD и коровник.
Есть: Корова { qr-code, name, age} Доить() Доярка {name} НачалаДоить() ПересталаДоить() Молоко { }
Закупщик молока { } ПродатьМолоко()
Надо это в код замапить.
Так вот, не надо изобретать какие то хитрожопые прослойки, доменные слои, реестры и прочую чешую. Все уже в Yii есть, просто используем готовый функционал.
Корова и доярка это ActiveRecord с необходимыми методами. молоко вообще не объект, а var:float
Закупщик молока - это сложная сущность в которой есть обращение к внешнему сервису закупщика, поэтому делаем как Service/Extension, чтобы изолировать от общего кода и ничего ни на что не зацепить случайно.
Собственно все. Дорка отмечает что начала доить, и по завершению сколько надоила. Это записывем как транзакции. А когда приезжает закупщик, дергаем ПродатьМолоко( 2000л ) и система делает записи учета и проводит транзакцию в 1С :)
0 дополнительных конструкций, только работа с тем функционалом что уже есть в Yii + код для бизнеслогики.
Потому что ДДД это не про код, а про понимание предметной области программистом и его коммуникации с нормальными людьми. А дальше ты сам решаешь какой инструментарий взять.
Корова { qr-code, name, age} Доить()
Доярка {name} НачалаДоить() ПересталаДоить()
Молоко { }
Закупщик молока { } ПродатьМолоко()
Алексей, в статье вместо Корова { } доить() имеется Сотрудник { } добавитьТелефон(телефон). Что здесь лишнее?
Твои комментарии :)
А если серьзно, то в нормально описанной предметке нет ничего лишнего. Если сотруднику добавляется телефон, то сотруднику добавляется телефон и никак иначе. Бери и пиши такой метод.
А если ты начал "ой да это противоречит принципам единственности ответственности..." то извините, но нам нужен другой программист.
Ну так этот метод addPhone и написан в предыдущей статье. Суть претензии в чём?
Никаких притензий :) Продолжай писать статьи.
Я тут кстати читаю книжку "Норвежский лес". Толстенная такая книженция, там автор на 250 страницах рассказывает как рубить дрова. Бестселлер говорят ;)
Конечно, на Yii можно это все сделать, но все это будет потом сложно поддерживать, так как будет сложно покрыть домен тестами.
Сами вбросили про DDD. Узнали, что ваш доклад не про DDD. Сами с собой поругались, обматерив чужие сущности с ООП и сразу же рассказав про свои такие же сущности с таким же ООП. И сами же слились. Забавно.
Алексей, давай на YiiConf ещё раз? Устроим холивар на сцене :)
С коллективной заявкой "Холивар по DDD" вместо докладов :)
могу рассказать почему надо немедленно бросить PHP перейти на golang чтобы не было мучительно жалко за молодых годы :)
Алексей, вы про какую известную всем книгу? Эванса?
Первые две статьи Дмитрия, про сущности и сервисы, интересные и полезные, возможно даже применимые к реальной жизни. А вот в первой статье про репозитории начался уже такой адский самопис, проксирование всякое, что не знаю кто сможет поддерживать такие проекты. Вроде и на фреймворки нас, пхп-разрабов, пересадили чтобы писать понятный поддерживаемый код. А здесь уже самопис чистой воды, от которого бизнес воротит. Пойди найди второго Елисеева, который сможет разобраться в художествах первого....
Геннадий, это не инструкция к действию. Это чтобы показать, как можно делать, как оно работает внутри. Для конвейера есть Doctrine 2 ORM.
Алексей, мне golang, конечно, симпатичен, но такая тема будет жестковата для YiiConf :) Ну и PHP не настолько плох, чтобы и его тоже использовать.
Геннадий, как сказал AntonZ, статьи Дмитрия — не призыв делать так и только так, хотя, конечно, тон повествования на это намекает. В любом случае, альтернативные подходы изучить очень полезно, как и дополнительные языки и парадигмы.
Да, и Doctrine 2 это "тяжелая артиллерия", для многих проектов можно DAO или AR, кому что удобнее, Главное, чтоб работать было приятно и проекты развивались