Шпаргалка по основам DDD
Aggregate root, Entity & Value object

#статья #хабр #ddd

Domain-Driven Design: чистая архитектура снизу доверху

#статья #sbertech #ddd

Помню как в бытность работы сисадмином столкнулся с версиями.

Не то, чтобы Semantic Versioning был для меня темным лесом и глядя на эти цифры, разделенные точками, я не понимал, что они значат.

Просто все эти обновления казались лотереей. Когда можно сразу накатить мажорную версию, а когда нужно было последовательно раскатывать все минорные версии.

Поэтому пришлось вникать глубже, чтобы разобраться в чем же отличие мажорной версии от минорной, что такое патч и почему накатив какую-то "незначительную" версию все ломалось.

Постепенно в голове сложилась картина: Major – это глобальные изменения, Minor – новые фичи, Patch – исправления багов.

Вот что пишет об этом Alex Xu

Semantic Versioning - это схема управления версиями программного обеспечения, состоящий из трех частей: MAJOR.MINOR.PATCH.

🔹 MAJOR: Увеличивается при несовместимых изменениях API

🔹 MINOR: Увеличивается при добавлении функциональности обратно совместимым образом

🔹 PATCH: Увеличивается при исправлении ошибок с обратной совместимостью

Серия видео с разбором глав одной из популярных книг по DDD Вона Вернона "Реализация методов предметно-ориентированного проектирования" от Сергея Черкашина, - инженера из Авито.Автотека

#ddd #youtube #обучение

Таинственный гул, который слышат лишь 2 процента людей, впервые записали!

Не спрашивайте зачем я об этом пишу, но как-то странно читать такие "научные" статьи, да еще и от инженеров. Один инженер провел исследования, другой решил написать об этом статью. Да еще и чуть ли не 60 лет не могли найти, да и вообще не верили в существование этого таинственного гула. Выглядит, если честно, как научное открытие высосанное из пальца.

Почему я так считаю? Просто потому, что я один из тех, кто этот гул слышит. Точнее слышал. А что изменилось? Да тупо сменил место жительства.

Как все начиналось. Давным-давно, когда галактика только начала расширяться после взрыва сверхновой. А нет, это другая история. В 2004 году недалеко от моего дома построили нефтеперекачивающую станцию. Вернее строить ее начали гораздо раньше, а вот запустили в 2004 году.

С тех пор я и стал слышать этот странный гул. Естественно слышен он был по ночам и то, если прислушаться. Но, я же в детстве смотрел фильмы про ковбоев и индейцев, поэтому первым делом приложил ухо к земле и тогда смог отчетливо услышать этот пульсирующий гул. Вот так была раскрыта тайна "таинственного гула". Извините за тавтологию. Хорошо, что все обошлось без дорогой аппаратуры и долгих исследований. Жаль, что такое лечится только переездом.

Не хотел разочаровывать инженеров-исследователей, но им бы почитать про поверхностные акустические волны, а то как в том анекдоте получается: Каким удивительным может быть мир, если в школе ты прогуливал физику.

#оффтоп

Пример проектирования, ориентированного на домен: От хаоса к чистой архитектуре

Перевел и выложил на Хабр статью по Domain-driven Design, которая показалось мне интересной. Автор Mirko Sertic, ссылка на оригинал тут

#статья #хабр #ddd

Начнем с видео от Lucid Software с учебным пособием по диаграммам классов UML. В этом видео на 9:40 приводится пример диаграммы классов, который вызвал у меня несколько вопросов. Попробуйте угадать, что может быть не так на этой диаграмме.

Всем доброго дня!
Время бездумной и беспощадной рекламной паузы подошло к концу, я надеюсь. Наступило время afternoon tea! Так что... наливайте в рюмки свой любимый напиток и ловите vibe

#vibe #music #youtube

В процессе изучения паттерна CQRS наткнулся на серию статей Арно Ланглада.

Вот эти статьи:
1. Command bus
2. Command and command handler
3. Validate a command
4. CQS vs CQRS

Вот что думает об этом AI:
Серия статей Арно Ланглада представляет собой всестороннее введение в паттерн CQRS (Command Query Responsibility Segregation) и связанные с ним концепции. Автор последовательно рассматривает ключевые элементы CQRS, предоставляя практические примеры и объяснения.

🔹 Шина команд (Command Bus Design Pattern): Арно начинает с объяснения роли шины команд в CQRS. Он описывает шину как центральный компонент, отвечающий за маршрутизацию команд к соответствующим обработчикам. В статье рассматриваются различные подходы к реализации шины команд и их преимущества.

🔹 Обработчики команд (Command Handler Patterns): Автор подробно рассматривает различные паттерны реализации обработчиков команд. Он объясняет, как обработчики команд выполняют бизнес-логику и модифицируют состояние системы в ответ на полученные команды. Статья охватывает важные аспекты, такие как обработка ошибок и обеспечение идемпотентности.

🔹 Валидация команд (How to Validate a Command): Валидация команд является важным аспектом обеспечения целостности данных и предотвращения ошибок. Арно описывает различные стратегии валидации команд, включая валидацию на стороне клиента, валидацию на стороне сервера и использование специализированных библиотек валидации.

🔹 Различия между CQS и CQRS (Difference Between CQS and CQRS Patterns): Арно четко разграничивает паттерны CQS (Command Query Separation) и CQRS. Он объясняет, что CQS предполагает разделение методов, изменяющих состояние системы, и методов, возвращающих данные, в то время как CQRS идет дальше и разделяет модели для записи и чтения данных.

Приятного прочтения.

#статья #CQRS #CQS #DDD

Подводные камни и закономерности CQRS
Уди Дахан - NDC Oslo 2023

По мере того как все больше разработчиков применяют Command/Query Responsibility Segregation в своих проектах, многие обнаруживают, что это увеличивает сложность систем, а не уменьшает ее, причем зачастую без какого-либо выигрыша в производительности. Присоединяйтесь к Уди и узнайте, в каких случаях следует, а в каких, что более важно, НЕОБХОДИМО использовать CQRS в своих проектах.

#CQRS #youtube

Всем привет. Немного мыслей вслух...

Почему-то в голове отложилось, что СТЕ это история про визуальное восприятие SQL запроса и необходимость написать понятный скрипт. В первую очередь для себя будущего, ну и для "того парня", который возможно будет читать твой запрос. Когда стоит задача разбить сложный и с наскоку мало понятный SQL запрос с вложенными подзапросами или временными таблицами, на простые и понятные любому мало-мальски знакомому с SQL части. Сам никогда не использовал, но в работе попадались такие запросы. Читать их было легче.

Пытался освежить в памяти, полез на Хабр и наткнулся на эту статью. Вот почему-то не смог осознать для чего автор этой статьи пытается сравнивать план запроса. Как будто скорость выполнения запросов для CTE является киллер фичей. Зато про рекурсию вскользь упомянул и молчок.

А что вы думаете по этому поводу? Используете CTE для написания сложных SQL запросов?

Физкульт привет!

Мой ✔️новый рекорд 🏆 по количеству шагов в день!

Забавная самокритика и инструкция для человека)

AI в 2025 году — это самый мощный калькулятор, который когда-либо изобретало человечество. Он может за секунду выдать ответ на сложнейшее уравнение.

Но если ты не знаешь основ арифметики, ты никогда не поймешь, не выдал ли он тебе полный бред.

Основы важны: Стажер-медик должен выучить анатомию прежде чем браться за скальпель.


Вот что, на мой взгляд, нужно делать.


Ментальная гигиена при работе с AI

Нужно вбить себе в голову несколько правил, как "Отче наш".

1. Сначала фундамент, потом ускоритель.
AI — не замена курсам, книгам и ментору. Это ускоритель для того, у кого уже есть база.

Прежде чем спросить у AI "как сделать X":
* Прочитай главу в книге об X.
* Посмотри лекцию об X.
* Попытайся сделать X сам, пусть и криво.
* И только когда застрял — идти к AI, но уже с конкретным, осмысленным вопросом.

2. Принцип нулевого доверия: "AI по умолчанию врёт".
Нужно выработать рефлекс: любой ответ от AI — это не истина, а гипотеза, которую нужно проверить. Получил кусок кода? Иди и проверь его в официальной документации. AI упомянул какой-то паттерн? Иди и прочитай о нем в книге. Ответ AI — это не конечная точка, а ссылка на то, что нужно изучить.

3. Стань самым надоедливым "почемучкой".
Никогда не принимай ответ как данность. Преврати AI в своего личного ментора, замучив его вопросами:
* "Окей, этот код работает. А почему он работает?"
* "Почему ты выбрал именно этот подход, а не другой?"
* "Какие у этого решения минусы и побочные эффекты?"
* "Напиши то же самое, но без использования библиотеки X".
Этот диалог заставляет не просто копировать, а понимать суть.

4. Используй AI как "резинового утенка" на стероидах.
Классический метод отладки — объяснить проблему резиновому утенку. Сам процесс формулирования вопроса часто наводит на решение. AI — идеальный "утенок". Пока будешь четко и внятно описывать свою проблему для AI, то с вероятностью 50% решишь её сам. А ответ AI будет приятным бонусом.

Новая реальность менторства

На сеньорах и тимлидах теперь лежит новая, еще более важная миссия.

1. Учить не "что делать", а "как проверять".
Раньше ментор показывал, как писать код. Теперь он должен показывать, как верифицировать код, сгенерированный AI. На код-ревью вопрос "Кто это написал?" становится бессмысленным.

Главный вопрос теперь: "Ты понимаешь каждую строчку этого кода? Объясни мне логику."

2. Задавать открытые вопросы.
Не "сделай фичу X", а "спроектируй решение для фичи X, опиши плюсы и минусы нескольких подходов". Такое задание нельзя просто скормить AI. Оно требует анализа, сравнения, то есть работы мысли, а не генерации.

3. Продвигать культуру первоисточников.
На любой вопрос ментор должен отвечать не готовым решением, а фразой: "А что по этому поводу говорит официальная документация / вот эта книга / вот эта статья?".

Приучать к тому, что истина — не в ChatGPT, а в проверенных источниках.

Сегодня AI — это не замена техническому писателю или инженеру. Это самый мощный в истории "умный черновик".

Как писать документацию с помощью AI:

1. AI пишет первый драфт. Он может взять 100 страниц кода и за 5 минут сгенерировать базовое описание для каждого метода. Это работа, на которую у человека ушли бы дни.
2. Человек-эксперт выполняет самую главную работу. Он берет этот черновик и превращает его в настоящую документацию. Он:
* Проверяет факты. То, что вы только что сделали со мной.
* Добавляет контекст. Объясняет, почему что-то сделано именно так.
* Находит неочевидные связи. Предупреждает о возможных проблемах.
* Берет на себя ответственность.

Что скажете?)

Всем привет!

Не успели оглянуться, а 2025 год уже подходит к концу — вместе с ним заканчивается и действие промокода BATORSKY2025. Напоминаю, что воспользоваться им можно до 31.12.2025 г.

Поздравляю всех с наступающим 2026 годом!

В новом году, возможно, начнём совместно читать книги по психологии. Ну, или небольшие брошюрки — чтобы было интересно и не слишком сложно.

Спасибо, что остаетесь с нами!

Дорогие друзья! С Новым годом! ✨

Работа... Учеба... Писать особо не о чем.

Из новостей...

Пополнил тут свою коллекцию "мондегринов" очередным шедевром и решил сохранить на память.

Ну а что, это же сундучок, да и песня со смыслом)

Даже если человек olvidarás,
Всегда нужно дать ему последний шанс.

https://music.yandex.ru/album/18530505/track/72044351?utm_source=desktop&utm_medium=copy_link