Что-то не то с уровнями вложенности. 5-6 уровней - возможно, агрегат стоит пересмотреть и разбить его на более мелкие.
Если есть необходимость менять сразу несколько агрегатов, то стандартный подход - доменные события. Не настолько это затратно по разработке, чтобы бизнес встал на дыбы. Тем более речь идёт о достаточно тяжелом приложении с аж 30+ агрегатами. Вложишься сейчас, сэкономишь время разработчика в будущем.
Свалка из сотен классов спецификаций может быть сгруппирована поагрегатно
Неоптимизированные запросы в случае спецификаций - известная проблема, которая решается упрощением агрегатов.
Если вас беспокоит невозможность переиспользовать спецификации в dapper, рассмотрите отказ от dapper в пользу любого другого orm с поддержкой iqueryable. Мне не совсем понятно, зачем при наличии EF вам второй orm, но если что то легковесное нужно - linq2db есть
"DDD подразумевает глубокую структуру папок по слоям" - вообще нет. Это clean architecture. Но вообще разделение на слои, наоборот, помогает ориентироваться в коде
"«Добавить поле в сущность» требует изменений в 10-15 файлах" - в большом коммерческом продукте это хорошо и правильно. Если у вас возникает очень часто такая необходимость, рассмотрите возможность работы с сущностями с динамическим набором атрибутов
Я тоже не пишу. И не собираюсь. В редких случаях, когда вообще нет ресурса, помогаю в проектировании бд, в аналитике, написание контрактов. Могу подсказать по архитектуре. Но все - именно как исключение из обычного рабочего процесса. Есть другие активности, которые не позволяют серьезно и вдумчиво погружаться в код.
Мало что погружаться, так ещё и нет предсказуемости в сроках
превращает аспекты из средства борьбы с boilerplate в инструмент принуждения к архитектурным стандартам, что особенно актуально в больших командах, где кодревью превращается в бесконечную войну с человеческим фактором.
Не видите противоречий? Отвергая один архстандарт, пытаетесь применить другой. И про код ревью уже по другому пишите
Во-первых, код ревью минимизирует ошибки, а не полностью предотвращает.
Во-вторых, даже вы сами говорите, что на код ревью отслеживаете качество кода. А если код не соответствует общепринятым практикам и правилами хорошего тона, он по любому некачественный. Так что ваш аргумент про код ревью говорит в мою пользу.
В-третьих, написание кода под системные вещи требует особого отношения. Как и в играх, зачастую жертвуют наглядностью и структурированностью в пользу быстродействия и экономии памяти. Поэтому сравнивать системный и прикладной код по одним и тем же критериям я бы не стал.
То, что вы где-то там principal engineer, это, безусловно, здорово. Но ваш стиль общения лично меня приводит к мысли, что вы - не командный игрок. Или слишком упиваетесь своими силами, делая атмосферу в команде токсичной.
Напоследок я бы хотел подчеркнуть ещё один нюанс. В 90% случаях в продуктовые команды не набирают суперпрофи. Их и на рынке не так много, и задачи, которые стоят перед командой, не требуют высокой квалификации. И бизнес не хочет платить высокую зарплату, если, абстрактно, уровень задач примерно "покрасить кнопку в другой цвет". Так вот, для таких не хватающие звёзд с небес людей следование перечисленным в статье концепциям и правилам это очень правильный путь.
А вам я желаю побольше сложных и нетривиальных вызовов, где вы можете и дальше поднимать свою квалификацию и свысока поплевывать на людишек снизу.
Вообще не вижу проблем. На планировании давать самые сложные задачи, установить на компьютер трекер активности со скринами, каждую невыполненную задачу фиксировать со служебной запиской, при оценке стабильно выставлять низкую. Варианты воздействия есть всегда.
Но это, согласитесь, идиотизм. И так вести себя - просто противно. Проще договориться и дать время на поиск работы (месяц, два), или выплатить компенсацию и по соглашению сторон.
В конце концов, рынок ИТ не такой большой, при устройстве на работу все равно пробивают человека (по крайней мере в крупных компаниях). Полюбовно расстаться, если не сработались, в интересах всех участников
Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
Тут не один агрегат, а много. И налицо событийная модель.
Если что, перевешивать в вашем примере нужно только владельца аккаунта. Все остальные сущности привязаны к аккаунту и не требуют миграции
Что видится мне:
Что-то не то с уровнями вложенности. 5-6 уровней - возможно, агрегат стоит пересмотреть и разбить его на более мелкие.
Если есть необходимость менять сразу несколько агрегатов, то стандартный подход - доменные события. Не настолько это затратно по разработке, чтобы бизнес встал на дыбы. Тем более речь идёт о достаточно тяжелом приложении с аж 30+ агрегатами. Вложишься сейчас, сэкономишь время разработчика в будущем.
Свалка из сотен классов спецификаций может быть сгруппирована поагрегатно
Неоптимизированные запросы в случае спецификаций - известная проблема, которая решается упрощением агрегатов.
Если вас беспокоит невозможность переиспользовать спецификации в dapper, рассмотрите отказ от dapper в пользу любого другого orm с поддержкой iqueryable. Мне не совсем понятно, зачем при наличии EF вам второй orm, но если что то легковесное нужно - linq2db есть
"DDD подразумевает глубокую структуру папок по слоям" - вообще нет. Это clean architecture. Но вообще разделение на слои, наоборот, помогает ориентироваться в коде
"«Добавить поле в сущность» требует изменений в 10-15 файлах" - в большом коммерческом продукте это хорошо и правильно. Если у вас возникает очень часто такая необходимость, рассмотрите возможность работы с сущностями с динамическим набором атрибутов
В тексте статьи четко написано про 5-6 уровней вложенности
Поделитесь, пожалуйста, примером агрегата с 5 (или больше) уровнями вложенности. Просто для расширения кругозора
А что, API gateway в точка банке не знают? Их же дофига. Хоть тот же TYK
Используйте ИИ. Будет виртуальный архитектор. Но лучше такой, чем вроде никакого
Спасибо
Диплодок же не умеет в on-premise? Ему нужно облако Яндекса?
Документацию пишет аналитик. Ну, хотя бы фт. Разработчики ругаются от необходимости ее писать.
У нас аналитик отвечает за доку. И кросс ревью только аналитики делают.
Сборку документацию не встроили в пайплайн, но есть ручная джоба по сборке документации из конкретной ветки. Запускаем для релизов
Наглядный пример того, что паттерн Катастрофоустойчивость является актуальным
Я тоже не пишу. И не собираюсь. В редких случаях, когда вообще нет ресурса, помогаю в проектировании бд, в аналитике, написание контрактов. Могу подсказать по архитектуре. Но все - именно как исключение из обычного рабочего процесса. Есть другие активности, которые не позволяют серьезно и вдумчиво погружаться в код.
Мало что погружаться, так ещё и нет предсказуемости в сроках
Ради интереса посмотрел другие и ваши статьи.
Цитата из последней:
превращает аспекты из средства борьбы с boilerplate в инструмент принуждения к архитектурным стандартам, что особенно актуально в больших командах, где кодревью превращается в бесконечную войну с человеческим фактором.
Не видите противоречий? Отвергая один архстандарт, пытаетесь применить другой. И про код ревью уже по другому пишите
Во-первых, код ревью минимизирует ошибки, а не полностью предотвращает.
Во-вторых, даже вы сами говорите, что на код ревью отслеживаете качество кода. А если код не соответствует общепринятым практикам и правилами хорошего тона, он по любому некачественный. Так что ваш аргумент про код ревью говорит в мою пользу.
В-третьих, написание кода под системные вещи требует особого отношения. Как и в играх, зачастую жертвуют наглядностью и структурированностью в пользу быстродействия и экономии памяти. Поэтому сравнивать системный и прикладной код по одним и тем же критериям я бы не стал.
То, что вы где-то там principal engineer, это, безусловно, здорово. Но ваш стиль общения лично меня приводит к мысли, что вы - не командный игрок. Или слишком упиваетесь своими силами, делая атмосферу в команде токсичной.
Напоследок я бы хотел подчеркнуть ещё один нюанс. В 90% случаях в продуктовые команды не набирают суперпрофи. Их и на рынке не так много, и задачи, которые стоят перед командой, не требуют высокой квалификации. И бизнес не хочет платить высокую зарплату, если, абстрактно, уровень задач примерно "покрасить кнопку в другой цвет". Так вот, для таких не хватающие звёзд с небес людей следование перечисленным в статье концепциям и правилам это очень правильный путь.
А вам я желаю побольше сложных и нетривиальных вызовов, где вы можете и дальше поднимать свою квалификацию и свысока поплевывать на людишек снизу.
Вообще не вижу проблем. На планировании давать самые сложные задачи, установить на компьютер трекер активности со скринами, каждую невыполненную задачу фиксировать со служебной запиской, при оценке стабильно выставлять низкую. Варианты воздействия есть всегда.
Но это, согласитесь, идиотизм. И так вести себя - просто противно. Проще договориться и дать время на поиск работы (месяц, два), или выплатить компенсацию и по соглашению сторон.
В конце концов, рынок ИТ не такой большой, при устройстве на работу все равно пробивают человека (по крайней мере в крупных компаниях). Полюбовно расстаться, если не сработались, в интересах всех участников
Легко. Просишь заменить на проекте или уйти по собственному. 99% не изображают из себя жертвы репрессий и уходят.
Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
А вы можете показать хоть одну закладку? Или включаете вашу фантазию?
Спасибо, про ограничения serial не знал
Spring state machine? ))