Проектирование сущностей предметной области, мысли
1 апреля 2017
Дмитрий Елисеев опубликовал у себя в блоге интересную статью: «Проектирование сущностей предметной области». Рекомендуется к прочтению и осознанию.
После прочтения возникают мысли и вопросы. Я был бы рад, если бы Дмитрий разобрал их в следующей статье.
Именование
Хорошо было бы заострить внимание на именовании: почему Employee, а не User. Имя в примере верно, но это не очевидно.
Агрегат
В начале статьи происходит резкий прыжок от ресурса к агрегату без объяснения, что такое агрегат и зачем он нужен. Если читатель не знает ничего об агрегатах, дальнейшие объяснения будут бесполезны.
Агрегат — набор сущностей, Entity, и объектов-значений, Value Object, которые рассматриваются как единое целое в контексте изменения данных. Если часть агрегата в процессе отказала, то ни одно из изменений не применяется.
У каждого агрегата есть корень, Aggregate Root, и границы. Корнем является одна из сущностей агрегата. Только на корень ссылаются внешние объекты. Ссылок на внутренние объекты агрегата быть не должно. Внутренние объекты агрегата могут внутри границ ссылаться друг на друга как угодно.
В будущем, при попытке добавить компанию, у которой тоже есть адрес, всплывёт логичный вопрос. Что делать с адресом сотрудника. Станет ли адрес новым агрегатом или всё же стоит ввести отдельные сущности для адресов: отдельно адрес сотрудника и отдельно адрес компании?
События
Об отложенных событиях в статье написано хорошо. Я бы специально выделил, что события в примере нужны, прежде всего, чтобы удовлетворить условия задачи:
И в его деле необходимо хранить историю помещения его в архив и восстановления.
В описание выше хорошо было бы добавить «и вообще историю любых изменений».
Исключения
В примере везде кидается один и тот же класс исключения \DomainException, что уже упомянули в комментариях. В идеале необходимо завести нужное количество конкретных исключений-наследников
чтобы знать причину без разбора строк.
Комментарии RSS по email OK
С указанными поправками это достойный ответ на заявления, что «ынтырпрайз»/правильная архитектура и Yii несовместимы.
Такие заявления далеко не безосновательны. Yii - RAD фреймворк, где поступились многим ради скорости. Синглтонов (типа Yii::$app), сервис-локаторов и сильной связи не должно быть в хорошо спроектированных проектах. Посмотрите класс yii\captcha\CapthaAction, сколько у него обязанностей? На мой взгляд Yii для другого - маленькие и средние проекты которые нужны вчера и которые не надо будет постоянно поддерживать. Сделали сайт, сдали, получили деньги. Ждать что yii подойдет для проектоа любого размера и с любым жц себе дороже.
AntonZ, а что для проектов уровня от среднего и которые надо поддерживать? Вопрос без подвоха, просто сейчас выбираю фреймворк.
AntonZ, классы самого фреймворка — да, не являются образцом академически верного ООП. Но это не мешает строить на нём сложные долгосрочные проекты. Тот же Stay.com не маленький, поддерживался и развивался в течение восьми лет. В Yii есть нормальный контейнер и совсем не обязательно использовать сервис локатор везде.
Если первый раз делаете большой проект - то берите то, что знаете. Хоть Yii, хоть CakePhp. Новый проект на новом для команды фреймворке - велик шанс все провалить. Для больших сейчас только symfony, zf3 как-то непопулярен, а жаль. Оба они требуют изучения и набивания руки на учебных проектах. В конечном итоге скорее всего поймете, что моделировать предметную область и тестировать легче, чем в Yii. Такие вопросы затем отпадут сами собой. Я не говорю, что Yii плохой, он нормальный, свои задачи решает, я сам на нем работаю и многое нравится.. Просто часто проскакивают заявления вроде "Я знаю Yii. Это самый лучший фреймворк. Зачем мне что-то еще". Люди замыкаются на Yii и воспринимают документацию как руководство по проектированию приложений. Это вредит и им и проектам. Поэтому и пишу такие комментарии, может у кого желание расширить кругозор возникнет.
SamDark, мое мнение такое: академичностью можно поступиться, когда вы про нее знаете, пробовали, писали, поняли, что где-то можно выиграть в скорости за счет сильной связи. Я думаю что поэтому вы и ушли от J2EE. Я считаю, что Yii именно для таких программистов, кто делал по канонам и у него получалось. Потом пришло понимание, что на простых или относительно простых проектах (большинство сайтов, заканчивая простыми интернет-магазинами) незачем везде делать слабую связность и где-то можно срезать. Yii дает для этого инструменты и много свободы, которая вредна всем тем, кто не пробовал делать по канонам и не видел как оно бывает по-другому.
Весь смысл Yii в отсутствии "академичности". Нужна "акдемичность" берите симфонию, нужно MVC - берите Yii, Laravel.
Может открою секрет - вашим клиентам плевать DDD у вас или нет, и 99% что ваш проект не принесет денег, лучше быстро запустить на простых моделях, чем потратить в 2 раза больше времени на "академичность".
Основной проект в нашей компании был написан в свое время просто отвратительно - но за 2 месяца, и начал приносить деньги практически сразу. За 7 лет был переписан до нормального состояния. 7 лет с этого проекта 13 человек получают зарплату.
И есть еще 4 проекта которые писались от полугода, до 3 лет, покрыты тестами, все модно и качественно. Принесли только убытки.
С точки зрения того кто тратит на это деньги - мне важнее быстрее запустится и понять принесет то деньги или нет, а не тратить в 2-3 раза больше денег на "в будущем будет хорошо поддерживать", оно может и не понадобится.
AntonZ, мне ничего не мешает использовать yii на полную силу, и следить за тенденциями php oop. без конфликтов
MVc это паттерн, придуманый в университетах. Это и есть академичность, которая вам так не нужна. В Yii MVC ркализован веьма сомнительно. AR это и строка в БД и форма с лейблпми и клиентской валидацией. Где туту разделение слоев?
Бизнес это бизнес, код это код. Я и говорил в первом посте, что на Yii колбасят по быстрому в продакшн, и вы только это подтвердили. Но там почти всегда плохой код.
Стас, это как надо было писать проект, чтоб его потом 7 лет приводить до нормального состояния? Я не согласен с такими подходами к работе. Это вам еще повезло, что была возможность приводить его до нормального состояния 7 лет.
А как вам такая ситуация - проект был написан за два месяца - там говнокод. Его запустили, он пошел приносить прибыль. Надо переписывать и развивать, иначе конкуренты задавят. А в проекте говнокод - очень сложно добавлять новые функции. Проект загибается. А у конкурентов все по методологиям с тестами. Они выкатывают новые фичи каждую неделю.
Доводили не все 7, но спустя 7 там все нормально. Есть и тесты и все остальное.
Естественно там был говнокод, но он приносил миллион в месяц уже в первый год. Самоокупаемость. Была на второй месяц работы. Но говнокод бы был если бы мы взяли и первую симфонию, и зенд, первый yii и т.д. Уже бы все устарело, все "не модно" и композера.
Программистам часто сложно объяснить , что лучше говнокод за 2 месяца (а всё-таки yii без ддд это не говнокод, и тесты никто не отменял ) , чем их анонизм на то, что сейчас модно и затягивание за счёт этого сроков в разы.
Если конечно деньги не платит добрый инвестор и можно на его деньги не спешить
А, извините. Я вас не так понял насчет семи лет)
Я думаю, что в вашем случае еще успешность и продуманность самой идеи и бизнес-процессов влияет. Ведь хороший или плохой код сами по себе не могут приносить деньги.
Тут палка о двух концах - сначала вложились в архитектуру и методологию - легче поддерживать и улучшать в течении длительного ЖЦ, но дольше писать. Не думали об архитектуре и писали кто как сочтет нужным - сделали быстро, запустились, потом долгий и болезненный рефакторинг.
Я сам не сторонник 100% академичности и паттернов. Я сторонник действительно модульного тестирования. А без применения DI оно не возможно. Работаю на Yii, но не бездумно - стараюсь писать эти самые модульные тесты. Это не так то просто. На симфе проектов не так то много, не говоря уж про зенд. Но если попадается, то там это дело поприятнее.