Доброе утро! ☕️ Маск снова в деле — он хочет купить OpenAI и вернуть компанию к опенсорсу.

Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.

Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥

Приятно аппетита, коллеги 🔥
У меня сегодня печеночка с салатиком, а у вас?!

🏗 DDD — от теории к практике: что это и как его внедрять

Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).

💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.

Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн


📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").

📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.

🔹 Базовая структура DDD-сервиса

/src
 ├── /order                # Контекст "Заказы"
 │   ├── /application      # Сценарии использования (Use Cases)
 │   │   ├── PlaceOrderHandler.py
 │   │   ├── CancelOrderHandler.py
 │   ├── /domain           # Бизнес-логика
 │   │   ├── /models       # Entities и Value Objects
 │   │   │   ├── Order.py
 │   │   │   ├── OrderItem.py
 │   │   │   ├── OrderStatus.py
 │   │   ├── /services     # Бизнес-сервисы (доменные)
 │   │   │   ├── OrderService.py
 │   │   │   ├── DiscountCalculator.py
 │   │   ├── /events       # Доменные события
 │   │   │   ├── OrderPlaced.py
 │   │   │   ├── OrderCancelled.py
 │   │   ├── /repositories # Абстракция работы с БД
 │   │   │   ├── OrderRepository.py
 │   ├── /infrastructure   # Взаимодействие с внешним миром
 │   │   ├── /persistence  # Реализация репозиториев
 │   │   │   ├── OrderSQLRepository.py
 │   │   ├── /messaging    # Интеграция с брокерами событий
 │   │   │   ├── KafkaPublisher.py
 │   │   ├── /external     # API-запросы к сторонним сервисам
 │   │   │   ├── PaymentGateway.py
 │   ├── /presentation     # API-интерфейсы
 │   │   ├── /http         # REST API
 │   │   │   ├── OrderController.py
 │   │   ├── /cli          # Консольные команды
 │   │   │   ├── ImportOrders.py
 │   │   ├── /events       # Обработчики событий
 │   │   │   ├── OrderPlacedListener.py
 ├── /customer             # Контекст "Клиенты"
 ├── /billing              # Контекст "Биллинг"
 ├── /shared               # Общий код между контекстами
 │   ├── /kernel           # Базовые интерфейсы и абстракции
 │   ├── /events           # Кросс-доменные события
 │   ├── /utils            # Хелперы и вспомогательные классы
 ├── main.py               # Точка входа
 ├── settings.py           # Конфигурация
 └── requirements.txt      # Зависимости

🛠 Как применять DDD в реальной жизни?
1️⃣ Определить домены — выделить ограниченные контексты и не смешивать их.
2️⃣ Говорить на языке бизнеса — если в компании термин "Клиент", то в коде это тоже "Клиент", а не "UserEntity".
3️⃣ Разделить слои — доменная логика, инфраструктура и интерфейсы не должны жить в одном месте.
4️⃣ Использовать событийную модель — "Заказ создан" → "Биллинг должен выставить счёт" → "Система уведомлений отправляет письмо".


DDD звучит круто, но на практике далеко не всегда оправдывает затраты. Вот основные минусы и подводные камни:

❌ 1. Сложность внедрения
DDD требует глубокого понимания бизнес-процессов. Нужно не просто писать код, а строить архитектуру вокруг бизнеса. Если команда не готова, получится монструозная система с кучей ненужных сущностей.

❌ 2. Избыточность для простых проектов
Если ты делаешь небольшой CRUD-сервис, то DDD – это перебор. Ограниченные контексты, доменные события и инфраструктурные слои только усложнят жизнь.

❌ 3. Высокий порог вхождения
Разработчикам, привыкшим к классическим архитектурам, будет больно. Код становится менее очевидным, а навигация требует знания всех контекстов.

❌ 4. Усложнение коммуникации
Если разделить систему неправильно, то контексты будут постоянно взаимодействовать друг с другом, создавая чрезмерную связанность. В итоге бизнес-логика снова расползётся, а команда утонет в согласованиях.

❌ 5. Зависимость от качества модели
Если на старте неправильно выделить домены, то всё пойдёт по наклонной. Переосмыслить архитектуру на поздних этапах очень дорого.

❌ 6. Замедление старта проекта
DDD требует времени на проектирование, а в реальном мире бизнесу нужны фичи вчера. В стартапах, где важна скорость, проще начать с простого решения, а DDD внедрять постепенно.

🎯 Когда DDD НЕ нужен?
❌ Если проект маленький (обычный CRUD)
❌ Если бизнес ещё сам не понял, как он работает
❌ Если команда не готова поддерживать сложную архитектуру
❌ Если продукту нужно быстро выйти на рынок

✅ Когда DDD полезен?
✔ Если система сложная, с множеством бизнес-правил
✔ Если команда готова работать с доменной моделью
✔ Если кодовая база разрастается и становится неуправляемой
✔ Если модель данных и бизнес-процессы стабильно развиваются

🚀 Итог
DDD — это не просто красивая архитектура, а философия проектирования. Она даёт:
✅ Читаемость кода
✅ Независимость контекстов
✅ Чёткие границы между доменами
Но если всё сделать неправильно, DDD превращается в хаос. 😅 Поэтому главное — не усложнять без необходимости.
Если твой код уже похож на лапшу, возможно, время пересмотреть его структуру. 🏗

Спокойной ночи! 🌙 Я иду спать, но в шоках, как сложно сделать миграцию схемы БД, если используешь Python 😅💥

Креативный отстойник: место, где рождаются гениальные идеи 🚀

Когда ты пишешь код, ты ведь не выкатываешь его сразу в прод? Сначала тесты, отладка, эксперименты. Так почему с идеями должно быть иначе?

У каждого разработчика должен быть Креативный отстойник — место, куда можно сливать все сырые, странные и на первый взгляд бесполезные идеи. Большинство из них, конечно, окажутся мусором. Но среди этого хаоса могут появиться инсайты, которые изменят твою жизнь и карьеру.

💡 Как работает Креативный отстойник?
Это твой личный Google Drive для мыслей. Сюда можно закидывать всё — от смелых технических решений до бизнес-идей и диких гипотез. Чем больше идей — тем выше шанс наткнуться на что-то стоящее.

🔥 Примеры идей, которые могли бы попасть в твой Креативный отстойник:
🔹 "А что если Telegram-бот может сам искать скидки и предлагать мне лучшие?" (Ой, кажется, уже реализовано 😏)
🔹 "А что если делать IT-курсы в формате ситкома?" (Представь курс по Kotlin, где студенты — герои сериала!)
🔹 "А что если разработчик мог бы кодить голосом без клавиатуры?" (Ну, голосовые помощники уже рядом...)
🔹 "А что если делать Reels, где ты объясняешь сложные IT-концепты на пальцах?" (Привет, бесплатный трафик на блог)
🔹 "А что если написать книгу, но каждую главу генерирует ИИ по ключевым словам?"

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

🚀 Как создать свой Креативный отстойник?
1️⃣ Фиксируй всё без фильтра. Заметки, голосовые сообщения в телеге, таблички в Obsidian — не важно, где. Главное, не доверять только памяти.
2️⃣ Выделяй время на пересмотр. Раз в месяц открывай архив идей и смотри на них свежим взглядом.
3️⃣ Связывай несвязанное. Иногда самые неожиданные сочетания дают лучший результат (например, чат-бот + мини-игры = твой новый стартап).
4️⃣ Не бойся абсурда. Сначала идея кажется глупой, а потом кто-то на ней делает миллионы (вспомни Flappy Bird).
5️⃣ Экспериментируй. Маленькие прототипы, MVP, тестовые запуски — не думай, а пробуй.

Креативный отстойник — это не просто свалка для идей. Это инкубатор будущих проектов, о которых ты пока даже не подозреваешь.

А куда ты сливаешь свои дикие идеи? Или до сих пор фильтруешь их на старте? 😏

#пробую

Коммент к посту:

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

#мем

Ну все я спать 🛌. Устал. Но победил yaml конфиг.
«YML лучший формат для конфигов»

Сегодня без постов. Вчера случилась одна очень личная и грустная штука. Надо переварить.

Небольшой респект-пост конторе, в которой я работаю 💜

Сегодня день был не самый простой — мало того, что эмоционально вымотался, так ещё и все заболели 🤒: малая с температурой и соплями, а Юлька, походу, чем-то ещё зацепила. Пришлось взять day off, потому что вообще не до работы.

Обычно я тот ещё массовик-затейник в детских играх 🎭, но сегодня совсем не до придумывания геймплея. Захожу в Самокат — а там смотрю, что купить можно… 👀

Пропустил пару новостей, вчера было не до этого. Но перед сном полистал ленту — и меня зацепила новость об обмене Винника.

⚡ Это имя у меня связано с первыми потерянными деньгами на крипте. Раньше была такая биржа — BTC-e, и я хранил там всю свою крипту. А потом в один день просыпаюсь, сайт не грузится ❌, а вместо кабинета — плашка "всё закрыто, приходите потом". Ну, а потом никто уже никуда не пришёл...

Через время биржу переименовали в WEX 🏴‍☠️, но что с ней сейчас — даже не знаю 🤷‍♂️

"Я сделал за 25 минут, а ваши спецы сколько будут ковыряться?" 🤡💥

💥 Вчера наш рабочий чатик разорвало провокационное сообщение из чата пользователей. Для контекста: мы разрабатываем внутренний сервис, а вот что написал один из юзеров:

"Мне нужно было привязать свою БД (канал в ТГ) и интегрировать скрипт в сервис. Потратил 25 минут, сделал примитивный интерфейс, и всё работает. Посмотрим, за сколько наши «спецы» справятся. Если, конечно, вообще обратят внимание."

И вот сижу, читаю это и понимаю — ну правда, мы так не можем. И вот почему:

🔹 Продуктовая команда не может знать о каждой хотелке. Кто-то один придумал себе кейс, но для нас это не всегда очевидно.
🔹 Приоритеты. У пользователей одна задача, а у нас — десятки, и далеко не все из них связаны с этим конкретным фич-реквестом.
🔹 Качество решения. Это не просто скрипт «на коленке» для себя. Нужно учесть дизайн, тестирование, безопасность, поддержку, документацию и так далее.

Но вообще, мне нравится, когда пользователи пытаются решать задачи самостоятельно. Это отличный пример того, как умение писать код может прокачивать даже не разработчиков. Ты либо ждёшь нужную фичу месяцами, либо просто пилишь её за вечер. 🚀

И это вообще топовый лайфхак для тех, кто ищет первую работу в IT или проект для портфолио.
Найди рутинную задачу, которую можно автоматизировать, и сделай для неё решение.

Я сам, когда работал инженером-проектировщиком на заводе, писал такие тулзы на коленке:
🛠 Считал неиспользованные контакты в разъёме
📊 Автоматически формировал отчёт по приходам и уходам
📂 Собрал базу данных чертежей

Вот такие проекты реальные, полезные и прокачивают.

#толки

Спокойной ночи, товарищи велосипедисты 🚴

#мем

Всем доброе утро ☀️
А я тут видос забавный скопил и в сторис ТГ выложил