ITKatya: культурные паттерны в IT

ITKatya: культурные паттерны в IT pinned «🤷‍♀️ «Делегируй или умри» — продолжаю обучение на курсе Стратоплана Лучше поздно, чем никогда — мой обзор 2ой трехдневки на курсе для CTO от Стратоплана. Тема звучала мощно: «Делегируй или умри»... На деле... нам делегировали изучить делегирование. А теперь…»

🤷‍♀️ «Делегируй или умри» — продолжаю обучение на курсе Стратоплана

Лучше поздно, чем никогда — мой обзор 2ой трехдневки на курсе для CTO от Стратоплана.
Тема звучала мощно: «Делегируй или умри»...
На деле... нам делегировали изучить делегирование.
А теперь по порядку!

Почему не писала раньше?
Во-первых, я и сам модуль слушала в разъездах — из Кипра через Ереван в Россию (СПб, МСК, СПб) и обратно. И еще в этих разъездах работала + ProITFest. А потом... просто все накопилось и навалилось!
Во-вторых, это пока самый спорный модуль для меня. А о спорном писать сложно! А я стараюсь писать честно, а не по инерции (на эмоциях).

Разбор по дням:
День 1 — про delivery, организацию поставки, каналы взаимодействия.
Неплохо, но делегирования не было. Просто не было.
День 2 — про процессы, работу с CEO (если он в командировках или на сцене), баланс между хаосом и структурой.
👉 Самый сильный день (спасибо Роме Иевлеву!). Именно за такими штуками я и пришла на курс — когда делятся живыми историями, когда видно, как оно «бывает на самом деле».
День 3 — про операционку, модель Cynefin, ITSM, ITIL.
Мы читали стандарты, обсуждали, зачем они нужны… но зачем нам это было здесь и сейчас — я так и не поняла. А главное: зачем "мы читали то, что мы уже читали"?

Что не зашло:
◾️ Ощущение разбалансировки между названием модуля и его содержанием.
◾️ Дискуссии в чате в конце модуля свелись к вопросу: а где тут вообще про делегирование?..
◾️ Геймификация — выглядит странно. Есть правильный ответ, и даже если ты можешь логично и уверенно обосновать другой — тебе говорят: «Ну, CEO (в игре) решил иначе». И ты не прав.
Да, это правда жизни. И такое бывает! Но в реальной жизни у тебя есть шанс влиять. А тут — нет. И это не обучает, а фрустрирует.
◾️ В кейсах мало обратной связи и мало обсуждения реальных решений. Просто: вот кейс, вот «правильный» ответ. Все.

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

А дальше?
Сегодня начинается новая трехдневка — про бизнес и тех-стратегии.
Вот на нее у меня очень большие ожидания.
Потому в компаниях, где я работала, я строила техническую стратегию — в связке с культурой, продуктом, бизнес-целями.
И мне очень хочется увидеть, как это делают другие.
Какие у других границы между тех и бизнес-частью. Как они миксуют.
Какие паттерны используют, а какие — обожглись и больше не трогают.

Так что ждем!
Может, просто модуль был не мой...
В любом случае — двигаемся дальше.
👀 Посмотрим, что будет.

С нами все хорошо!

Сегодня была самая сложная и самая страшная ночь на Кипре.

На острове трагедия! Случились 2 пожара, один из которых рекордный. Но, сейчас огонь взят под контроль.

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

Но сейчас-утро, и все хорошо. Остров восстановится и отстроится. А внутри только очень много благодарности и признательности тем, кто всю ночь противостоял стихии!

📚 Что такое пост-документация в DDD?

Все, финальная часть про DDD.
Весь путь: про стейкхолдеров и бизнес, про проектирование, про разработку, про тестирование.

Это не только «техописания» и не столько API.
Это — фиксация моделей, бизнес-решений, контекстов и ограничений, с которыми вы проектировали и кодили.
И важно: такая документация пишется в процессе работы, а финализируется не по окончании проекта, а когда принято финальное решение, позволяющее ее финализировать.

1. Зачем вообще она нужна?
📉 Модели теряются. Через 6 месяцев никто не помнит, почему Transaction и Adjustment — это два разных агрегата.
💬 Команда меняется. Новичкам сложно въехать в неочевидные решения.
🧩 Интеграции множатся. Без явной документации контексты путаются, границы стираются, начинается ад из «просто использовали не по назначению чужую сущность».
🤒 Клиенты (любых видов) не должны страдать. А значит им нужна своевременная и понятная документация на их языке.

2. Что фиксируем:
Bounded Context-ы:
— их границы, название, бизнес-смысл
— где их API, с кем они взаимодействуют
Ubiquitous Language:
— глоссарий терминов
— амбигуозности
— кто как называет “клиента” и “транзакцию” — и почему
Доменные модели:
— диаграммы (в т.ч. Event Storming)
— паттерны, которые вы внедрили
— архитектурные компромиссы, которые пришлось принять
Бизнес-решения:
— почему поведение системы именно такое
— какая гипотеза лежала в основе
— что было сделано «временным решением» (и когда его пересматривать)

3. В чем особенность DDD-документации:
Она пишется на языке бизнеса, а не только техническом.
Она живет рядом с кодом — в wiki, в ADR-нотах, в репозиториях, а не в спрятанных PDF.
Она строится по мере развития модели, а не «в конце проекта».

4. А в чем сложность?
– Нужен тот, кто будет ее писать! Бизнес считает, что документация — дело разработчиков. Разработчики считают, что это «долго и не нужно».
– Стоимость! Никто не хочет платить за «ничего» — а ведь пост-документация и есть ваш антидолг. Она сохраняет знания, которые иначе потеряются.
В DDD документация логично завершает каждый виток моделирования.

Отдельно про финтех: Финансовые организации зачастую должны готовить документацию для регуляторов или партнеров. DDD здесь – палочка-выручалочка, потому что наличие четкой модели и терминологии позволяет сравнительно легко написать необходимые описания. Например, для сертификации PCI DSS может потребоваться описать потоки данных карточных транзакций – команда, имея на руках контекстную диаграмму и описание событий, подготовит такой документ быстрее.

#architecture #ddd

🧪 Тесты при DDD — инструмент контроля поведения.

1. Тестируется поведение, а не реализация
Мы не проверяем, что метод вернул массив из 4 элементов.
Мы проверяем, что при таких входных данных InvoiceLimitPolicy запрещает оплату.
Это называется specification by example — описание бизнес-логики через конкретные кейсы.


2. Тест в связке с бизнес-языком
Тест test_cannot_exceed_limit_for_vip_clients читается без перевода.
Никаких «тестируем что метод х вызвал метод у». Мы проверяем бизнес-правила, а не детали реализации.

3. Плюсы:
✅ Повышается устойчивость к изменениям — вы можете менять реализацию, пока поведение не ломается.
✅ Тесты = документация. Для нового разработчика часто тест — первый вход в контекст.
✅ Бизнес понимает, о чем речь, а еще им можно «сплавить» проверку тестовых сценариев (и они их проверяют лучше команды разработки).

4. Минусы:
− Это требует времени и дисциплины. Легче протестировать функцию, чем поведение домена.
− Иногда сложно определить границы — а это уже вопрос к архитектуре.

5. Качество ≠ Тесты
Тестов может быть много, а система — неудобной, сложной, не отражающей суть бизнеса.
В DDD качество = насколько хорошо система отражает домен:
− насколько точно реализованы правила,
− насколько понятно поведение,
− насколько просто объяснить, что делает система.
И здесь тестирование — лишь один из инструментов обеспечения качества, наряду с ubiquitous language, совместным проектированием и проверками модели.

6. А при чем тут TDD?
TDD (Test-Driven Development) идеально сочетается с DDD:
− сначала описываешь поведение,
− потом реализуешь,
− потом рефакторишь, не боясь поломать.
Но важно: TDD — это не про «сперва написать тест», а про мышление через поведение.
DDD-тесты не про проверку кода, а про проверку бизнес-правды.
Когда пользователь говорит: «у нас нельзя так делать», а ты открываешь тест и видишь — да, нельзя. Или, наоборот, понимаешь, что это поведение вытекает из старой логики и требует пересмотра.

Завтра — финальный пост: пост-документация и ее смысл в DDD.
💬 А у вас тесты — это safety net или описание модели?

#architecture #ddd

Добавим в интеллектуальное немного 🤏 «веселенького»…

Делюсь любимыми шуточками про DDD:

DDD — это когда ты потратил 3 месяца, чтобы объяснить бэкенду, что «заказ» и «подписка» — не одно и то же.
И еще 3 месяца — чтобы поверить в это самому.

— У нас 4 команды, один домен.
— Это не DDD, это shared trauma.

Когда архитекторы говорят "bounded context", они имеют в виду "давайте разойдемся и не будем пересекаться".

💻 Что значит “разработка по DDD”?

Продолжаю серию постов по DDD. А если пропустили, то: пост1 и пост2.

Внезапно DDD не про «сделать микросервис» или «назвать package domain».
DDD в на уровне реализации — это когда код говорит на том же языке, что и бизнес, и этот язык не ломается по дороге от требования до продакшна.
Да, та самая проекция бизнеса на код!

1. Что это дает:
🧠 Проекция модели
Главый постулат: бизнес-логика в коде = бизнес-логика в головах.
Сервис PaymentLimitChecker вместо SomeUtils.calculate() — и уже ясно, о чем речь.
📚 Код как документ
Не надо искать ТЗ или копаться в Confluence. Код читается как описание предметной области — потому что оно и есть.
А еще проще онбодинг, а вся компания на шаг ближе к обезличенному коду.
🧩 Модулярность не по слоям, а по смыслу
Если бизнес-правило живет в отдельной сущности, его легче тестировать, изменять и обсуждать.
А если вся логика в контроллере — нет ни контроля, ни логики.

2. Когда DDD мешает:
— если вы «наслоили паттернов», но никто не понимает, зачем эти ValueObject и Aggregate;
— если всt ради красоты — но бизнес до сих пор зовет кнопку «фильтр» там, где в коде OperationController.

3. Почему в DDD разработчики становятся проектировщиками?
Потому что именно они делают последние (и ключевые!) проектные решения:
— куда положить правило?
— как назвать сущность?
— разделить сущность или расширить типизацию?
Это уже архитектура, только реализованная на уровне строк кода.
DDD говорит: если ты пишешь логику — ты проектируешь. И тебе нужен язык, с которым ты можешь это делать корректно.

4. DDD != антипаттерн слоев, как и DDD != слои
Если ваша архитектура:
- слой контроллеров
- слой сервисов
- слой API
…и все это в одном Bounded Context — это еще не DDD.
Так же как и запиленный небольшой монолитик, но если он Bounded Context вполне может быть DDD.

Бизнес говорит: «нельзя переводить больше 300 000₽ в сутки».
Вы:
1) не хардкодите «300000» в 5 местах,
2) создаете TransferLimit и Policy,
3) называете метод canTransferToday(amount)
И этим создаете язык, на котором можно говорить с бизнесом — в коде.

DDD в реализации — не стиль кода. Это инструмент для мышления, который позволяет писать системы, которые будут жить, а не сползать в баги и затычки.

Завтра — про тестирование: как проверять поведение, а не строки.
💬 А у вас код с бизнесом на одном языке?

#architecture #ddd

📚 Как Катя учит язык 🚉

Я вас тут начала грузить постами про DDD и, кажется, они даже кому-то заходят. Но по-настоящему, конечно, все фанатеют от моих постов про то, как я учу язык. Так вот — выходной, значит, давайте про язык.

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

Во-первых: «вокзал». Весь мир использует слово station — это железнодорожная станция, точка на маршруте. А только в русском есть специальное слово для здания при станции — «вокзал».

Что особенно забавно: это заимствование из английского — но искаженное и переосмысленное. История такая: в 1830-х, когда строили первую железную дорогу от Петербурга до Царского Села, англичане поставляли чертежи и оборудование. На одном из чертежей было написано Vauxhall Station — по названию района в Лондоне. Русские инженеры решили, что «Vauxhall» — это не название, а общее слово для здания при станции. И с тех пор у нас появился «вокзал».

Это один из тех примеров, когда слово, попадая из одного языка в другой, приобретает новое значение, которого в исходном языке не было. Отсюда — логичный мостик ко второй теме: словам, которые описывают двойственность.

Если вы читали мой первый пост про DDD, вы могли заметить термин «амбигуозность». Если вы попытаетесь загуглить его, Google вежливо поправит: «Вы имели в виду амбициозность?» — Нет, не имеете! Так как слово такое действительно существует!

Ambiguity / ambiguous — это устойчивый английский термин, особенно в юридическом и инженерном контексте. Он обозначает неопределенность, двусмысленность, невозможность однозначной трактовки. Например: ambiguous clause в контракте, который допускает разные интерпретации. В русском же языке почти никто не говорит «амбигуозный». Вместо этого — «неясность формулировки», «двойственное толкование», «правовая коллизия», а иногда — «аморфность».

Но есть одно слово (тоже связано с двойственностью), которое в русском и английском совпадает — это «амбивалентность».

Первоначально это химический термин: он описывает элемент, способный проявлять разные валентности — то есть, присоединять различное число связей, в зависимости от условий. Например, железо может быть Fe²⁺ или Fe³⁺ — это разные степени окисления, то есть разные валентности.

Позже термин перекочевал в психологию, и уже там приобрел значение одновременного наличия противоположных чувств или оценок к одному объекту. Амбивалентность — это когда вы любите и злитесь одновременно. Или — хотите перемен, но боитесь. То есть снова — двойственность, но на уровне эмоций и восприятия.

Вот такой вот мир языковых и смысловых сдвигов.
А на фото — та самая станция Vauxhall и Витебский вокзал, с которых все и началось.

🏗 Как DDD помогает на этапе архитектуры и проектирования

1. Делит по смыслу, а не по слоям
DDD предлагает смотреть на систему как на совокупность смысловых контекстов, а не просто «вот тут сервис, вот тут контроллер».
Архитектура строится по бизнес-логике, а не по технологическим паттернам.
→ Вместо «сервис каталога» — «управление товарными категориями».
→ Вместо «бэк-офис» — «расчет комиссий».
📦 Это дает:
— ясные границы владения данными и логикой,
— меньше связей между частями системы,
— выше устойчивость к изменениям.

2. Позволяет не смешивать несовместимое
Если в одном модуле встречаются и бизнес-логика, и интеграции, и админ-панель, и метрики — это все пахнет монолитом боли (но не всегда! И, да, только на длительной дистанции!).
DDD подсказывает: все, что живет по разным правилам — должно жить в разных контекстах.
🧠 Пример: расчет пеней по кредитам и формирование/выдача индивидуальных кредитов — разные контексты. Разный язык, разная частота изменений, разные источники истины.

3. Как мешает (если применять неправильно)
— Переусложнение на старте
Выделять bounded context ради bounded context — вредно.
Если вы на MVP стадии и продукт еще не понял сам себя — не надо ваять архитектуру на 100 лет вперед.
— Слишком формально
DDD — это не UML и не жесткий шаблон.
Если вы пишете спецификацию на каждый value object, но не можете поговорить с бизнесом — это не DDD, это бюрократия.

4. Связь с языком и контекстами
Каждое архитектурное решение должно проходить через язык:

— Как называется эта часть?
— Какие слова в ней допустимы?
— В каком контексте они значат то, что значат?

Если внутри одного bounded context у вас есть «user», который одновременно и платит, и нанимает, и модератор — это уже тревожный звонок.
🎯 Проверка: можно ли без ошибок перевести требования бизнеса в термины архитектуры?

5. Как проверять деление на домены и замкнутость контекстов
— Есть ли своя модель данных?
— Есть ли уникальные бизнес-правила?
— Меняются ли эти правила независимо от других частей?
— Понимает ли одна и та же команда, как это работает?
— Можно ли заменить этот контекст без масштабного рефакторинга всей системы?
Если «да» — у вас скорее всего здоровый bounded context.

🤔 Всегда ли нужно?
Нет. Если у вас микропроект на 3 человека — достаточно здравого смысла.
Но если проект растет, появляется несколько команд, увеличивается сложность, разрастается предметная область — без архитектурных принципов DDD вы начнете тонуть в хаосе.

Практические примеры (финтех):
Интернет-банк разбивается на контексты: «Accounts» (Счета), «Payments» (Платежи), «Loans» (Кредиты), «Cards» (Карты), «Analytics/Reporting» (Отчеты). Каждый из них соответствует своей части бизнеса и управляется отдельной командой. Например, команда контекста Payments владеет всем, что связано с переводами: у них свой словарь (платеж, транзакция, комиссионные и т.д.) и своя кодовая база. В другом контексте Accounts – свой словарь (баланс, счет, клиент и т.п.). Эти команды работают параллельно, а взаимодействуют их сервисы через четко определенные API. При этом термин «Transaction» в контексте платежей имеет одно значение (конкретное движение денег), а в контексте аналитики, скажем, это может быть абстрактный объект для агрегированной статистики. Благодаря DDD эти понятия разведены: без выделения контекстов компания получила бы единую громоздкую систему, где разные отделы говорили бы «транзакция» о разном и путали друг друга. 
В этом примере команда Accounts и команда Payments могут работать автономно, выпуская изменения независимо – изменение в сервисе счетов не сломает сервис платежей, если контракт (например, API запроса баланса) остался прежним.

В понедельник поговорим про разработку и реализацию, а пока:
💬 Ваша архитектура отражает бизнес? Или просто похожа на «все как у людей»?

#architecture #ddd

🧠 Что дает DDD на этапе сбора требований и всех этапах взаимодействия с бизнесом?

1. Сбор требований — это не просто список хотелок
В DDD важно не просто услышать, что «нужно сделать кнопку», а понять, в каком домене живет эта кнопка, какую бизнес-ценность она несет, и какой словарь у людей, которые ее хотят.
Наша задача — достроить ментальную модель бизнеса, а не просто получить бэклог.
🧩 Инструменты: Event Storming, Domain Storytelling, бизнес-интервью на основе Ubiquitous Language.

2. Единый язык (Ubiquitous Language)
Если у разных ролей (аналитики, архитекторы, продакты, пользователи) — разный словарь, проект обречен на баги из-за недопонимания.
Именно на этапе сбора требований надо:
— фиксировать термины, особенно амбигуозные (например, «клиент» может быть и физлицом, и юридическим лицом, и API-интегратором)
— называть вещи бизнес-словами, а не «экран 3», «процесс 5», «где-то там фильтр»
— не бояться обсуждать, что такое “правильно” в глазах бизнеса
🎯 DDD здесь учит нас: не просто спросить “что сделать”, а выяснить “какое поведение считается корректным” и “почему именно так”.

3. Проектирование — это уже часть коммуникации
На этапе общения с бизнесом может (и должно!) рождаться проектное мышление:
— а как это будет разделено на bounded context-ы?
— это новая подсистема или расширение существующей?
— а эта функция — чей юрисдикции, какого домена?
⛓️‍💥DDD позволяет сразу задать границы, чтобы избежать каши из связей и зависимостей в будущем.

4. Поиск доменных экспертов — не пункт в чеклисте, а процесс
Если вам повезло и у вас есть живой domain expert — берегите его! Но чаще всего их приходится выращивать внутри компании.
DDD говорит: доменный эксперт — это не титул, а функция.
Это может быть продакт, клиент, юрист, кастомер-саппорт — тот, кто лучше других понимает бизнес-правила в конкретной области.
🧩 На этапе сбора требований это значит:
— слушать больше,
— задавать наводящие вопросы,
— и замечать, кто из собеседников реально может объяснить, почему система устроена именно так.

5. Где сложности?
💭 Бизнес не привык мыслить через модели. Ему нужно «чтобы работало», а не «bounded context с единым языком».
🤢 Слово “домен” часто вызывает отторжение. Его путают с “сферой” или ДАЖЕ “базой данных”.
🤝 Нет привычки к коллаборации. Распространена модель «продукт пишет ТЗ → разработка делает».
DDD требует совместного проектирования.

6. Коллаборация — главный инструмент
Если на этом этапе вы не сделали язык совместным, никакой code-first не спасет.
Поэтому:
– Стенормьте встречи с разными ролями
– Пробуйте фасилитации (Event Storming прекрасно заходит с бизнесом)
– Делайте схемы, рисуйте!
– И фиксируйте все: термины, допущения, ограничения, цели

Следующий пост (завтра) — про архитектуру и проектирование.
💬 А пока расскажите: на вашем проекте язык между командами был единым? Или каждый понимал по-своему?

#architecture #ddd

🧩 DDD — это не только про архитектуру. Это про культуру!
Начинаю серию постов о применении Domain-Driven Design на всех этапах создания продукта.

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

Про DDD часто говорят так:

– «Это подход к проектированию»
– «Нет, это про моделирование кода!»
– «На тестировании нам DDD не нужен, там TDD»
– «Это для сложных систем, а мы MVP делаем»

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

В этой серии постов я хочу пройти по всем ключевым этапам разработки цифрового продукта до вывода на прод, и показать, как DDD помогает (и где мешает):
1) Сбор требований, работа со стейкхолдерами
2) Архитектура и проектирование
3) Разработка и реализация
4) Тестирование
5) Пост-документация и передача знаний

И сегодня про этап 1: Сбор требований и взаимодействие со стейкхолдерами.
Сам пост уже ниже 👇

#architecture #ddd

👍 Утренняя рекомендашка! 👍

В эту субботу моя подруга и мой трекер Юля Балдина проводит бесплатный мастер-класс про бизнес-процессы и операционку.

Если ты не знаешь, что такое трекер — это тот самый человек, который не будет гладить по голове, а скажет честно:
что у тебя не так, где деньги утекают, куда уходит время команды и почему автоматизация не спасает, а калечит ("пиздюлятор" для управленцев).

Юля именно такая. Много лет работает по ту сторону процессов — там, где их собирают, чинят и масштабируют.
И она умеет показать:
— где у тебя в компании зарыты деньги,
— как перепрошить кейсы на рост,
— и почему «ну вроде работает» — это не норм.

📌 Даже если ты не операционный директор — будет полезно. Потому что посмотреть на процессы глазами операционки — это вообще отдельный скилл.

📎 Вот пост с записью на бесплатный МК

Идите. Потом спасибо скажете.

🧩 А что такое домен, простите?

Я тут вернулась после 2х недель командировок, конференций и мини-отпуска и пока меня окунает в омут всего скопившегося. И немножечко меня окунуло в DDD.

DDD — вроде бы про язык. Про общее понимание между бизнесом и разработкой. Про то, чтобы сложное стало чуть понятнее. А теперь откройте любую из «каноничных» книг по DDD. Хотите у Эванса, хотите у Вернона. Хотите даже у Хононова. А теперь найдите там внятное определение домена. 🙃

Сюрприз: его там… нет. Есть

Domain (noun)
a sphere of knowledge, influence, or activity.
(сфера знаний, влияния или деятельности)
Словарь Мерриам-Вебстера

И есть «реальность бизнеса». Есть «область, где компания зарабатывает деньги». И вроде бы звучит хорошо — но когда ты на митапе или на курсе начинаешь объяснять, «что такое домен», и люди в зуме кивают, а потом кто-то говорит, что у него домен — это API, ты понимаешь, что все не так просто.

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

Домен – это ограниченная часть бизнеса, имеющая свою бизнес-ценность (отдельно оцениваемую), позволяющая при его исключении, работать остальным доменам бизнеса в рамках их основного продуктового назначения, с частичной (или отсутствующей) деградацией.

Звучит сухо, но очень помогает. Вот убрать «платежи» — и остальное работает, просто не зарабатывает. А вот убрать «логистику» — и часть бизнеса встанет, но остальное будет жить. Значит, это отдельные домены. А вот «авторизация» — это не бизнес-домен, а скорее техническая компонента, обвязка.

Важно: я не настаиваю, что это единственное правильное определение. Но пока — это единственное, которое мне действительно помогает дизайнить архитектуру и язык.
С ним можно обсуждать приоритеты. Можно находить ядро. Можно на пальцах объяснить, почему часть системы — это не просто модуль, а именно бизнес-домен со своей логикой и ценностью.

Хотя термин «домен» в контексте DDD порой размытый, важно явно договариваться о его значении в каждом конкретном случае. Авторы основных книг по DDD – Эванс, Вернон, Хононов – закладывают понимание домена как предметной области бизнеса, но уровень этой области может различаться (весь бизнес vs. отдельная функция). Если мы уточним, что домен – это обособленная часть бизнеса с самостоятельной ценностью, то получим более четкую основу для стратегического дизайна.

💬 А вы как определяете «домен» в своей работе? И как объясняете это команде?

#architecture

🛡 Навеянное питерской погодой 🛡

Лето. Кому-то полегчало. А кто-то говорит страшную фразу на 1:1: «Сейчас-то я еще держусь. А вот как осенью — не знаю…»
Мы не всегда можем «победить». Не всегда справляемся. Но можно пройти этот путь иначе.
Наткнулась на интересную модель ARMOR — она показалась очень человечной.

ARMOR — не про устойчивость, а про не развалиться. Ребята из Lenny’s Newsletter по итогам исследования о выгорании ITшников (полная версия по подписке), составили стратегию борьбы с выгоранием.

A: Autonomy (автономия)
1. Контроль за временем.
Свободное время под важное не появится само.
Люди, прошедшие через выгорание, расчищают календарь, бронируют слоты на фокус и убирают все, что мешает.
2. Доверие не просят — его зарабатывают.
Ты не получаешь автономию — ты ее создаешь делами. Выполняй обещания. Работай прозрачно. Это будет самый сложный пункт, так как в выгоревшем состоянии держать слово - сложно!
3. Словами через рот - проговаривать вслух ВСЕ.
Что делаешь, как работаешь, где твои границы.
Не просто «что», а и «как». Про это напишу как-нибудь отдельно.
Автономия — не вседозволенность. Это возможность работать долго, стабильно и без внутреннего перегрева.

R — Resilience (Незыблемые границы)
1. Границы нужны всегда — даже микроскопические.
«Заканчиваю в 18:00», «Не больше 3 приоритетных задач в день», отказ от мессенджеров вне рабочего времени, выключение всего в отпуске. Это не слабость — это осознанность.
2. Слово «нет» — твой щит.
Каждое «да» чему-то — это «нет» чему-то другому.
Умение аргументированно отказывать спасает фокус, энергию и уважение к себе.
3. Настоящие перерывы — не прокрастинация, а защита.
Регулярные, восстанавливающие, с переключением контекста.
Когда в ресурсе — выкладывайся. Но дай себе право на передышку.
Границы — не про стену. Это возможность жить и работать структурно.

M — Maintenance rituals (Ритуалы ухода за собой)
1. Сон — твой главный алерт.
Если ты плохо спишь две ночи подряд — это инцидент.
Люди, пережившие выгорание, не героствуют: они отлаживают режим, уменьшают шум перед сном, идут к специалисту, если не справляются сами.
2. Движение — как обязательный health-check.
Прогулки, разминки, тренировки — не опция, а гигиена психики и тела.
Даже 15 минут активного тела — это минус тревога, плюс ясность.
3. Питание и терапия — часть архитектуры устойчивости.
Люди, умеющие не сгорать, не пропускают приемы пищи и не игнорируют психотерапевта/иную врачебную помощь. Это профилактика падения вашего продакшена.
Maintenance — не про баловство. Это настройка системы, в которой ты — и есть система.

O — Original Thinking (Собственная система убеждений)
1. Осознанность границ ответственности.
Плохая оргструктура? Токсичный процесс? Это не твоя вина. И не твоя зона контроля.
Если ты видишь, что кто-то рушит компанию, но ты не ее собственник, возьми попкорн и наблюдай. Дай людям совершить ошибки. Главное будь в безопасности!
2. Разрешить себе быть несчастным.
Не надо «быть молодцом» каждый день. Не надо улыбаться на стендапах, когда выгорел внутри.
Люди, сохранившие себя, умеют признавать эмоции и не тушат их насильно.
3. Меньше «я должен», больше «я могу»/«я хочу».
Разберись в том, что для тебя важно и делай именно это!
Original thinking — внутренний фрейм: как ты воспринимаешь себя и свою работу.

R — Role Architecture (Архитектура карьеры)
1. Выбирай не логотип, а людей.
Хороший бренд — это красиво, но поддержка в команде важнее.
Безопасная атмосфера = лучший инструмент от выгорания.
К сожалению, я проверила эту гипотезу на себе. И могу ее подтвердить на все 100!
2. Тест на воскресенье.
Если по воскресеньям тебя «пучит» от мысли о завтра — меняй работу.
Идти туда, где тебе легче дышать!
3. Позиция должна соответствовать масштабу.
Размытые задачи и неясные ожидания выжигают хуже переработок.
Архитектура роли — про понимание: где твоя зона влияния и где заканчивается твоя ответственность.

При кажущейся простоте за каждым пунктом скрывается уйма работы. Но цифра >50% выгоревших - пугает...

А я заметила, что без солнца больше думаешь про тщетность бытия!

#people_management

🎭 Если можешь не создавать — не создавай!
Вчера была на премьере в Театре Ленсовета.
«Театральный роман». По Булгакову. Спектакль соединивший в себе "Записки покойника" и "Белую гвардию".

И знаете — не понравилось.
Для меня это попытка упростить «Турбиных». Убрать нюансы, добавить пафоса и лишней буффанады и увести в сторону.
Но! Я не могу сказать, что спектакль не навел ни на какие мысли. Как раз наоборот — навел. И довольно точно.

Иногда мы сами становимся авторами. Не обязательно книг или пьес.
Архитектура. Продукт. Код. Процесс. Тест. Да что угодно.
И вот ты что-то делаешь. А рядом есть другие люди — не всегда из твоей сферы.
Они что-то советуют. Исходя из своего опыта, своих целей, и своей политики.

И ты как тот герой из Булгакова — можешь:
— переписать в угоду критикам,
— упереться и остаться в столе,
— или искать третий путь, где ни ты, ни твое детище особо никому не нужны.

💬 Я вспомнила старое интервью Саши Васильева (группа «Сплин»).
На вопрос «как сделать хит?» он ответил:

«Для меня есть только один способ добиться успеха – писать сильные интересные яркие песни»

И вот это, кажется, применимо ко всему.
К песням. К постам. К коду. К продуктам.
Если можешь не делать — не делай. А если не можешь не делать — значит, уже все решил.

Завтра выхожу из мини-отпуска — и начинается ВСЕ: работа, встречи, дорога домой на Кипр.
Плюс размышления: ехать ли на Highload или TeamLead? И если ехать, то с чем? Потому что тема, которая моя, личная, любимая — не всегда укладывается в формат доклада. Зато может стать курсом, а я вместо написания книги/курса пишу небольшие статьи...

Так что, наверное, пора перестать страдать и просто начать делать.
А пост, возможно, прежде всего для себя.

А еще я вписалась в конкурс Tg-каналов от ребят из TG Contest, в котором участвуют экспертные каналы с авторским контентом. Цель: "слет юных блогеров" и помощь друг другу в поиске релевантной аудитории. Я в секции «Разработка и управление командой» и вот тут можно даже за меня голосовать (за что я конечно же буду вам признательна: ссылка на голосование 👍).

🗂А еще мы собрали папочку со спикерами нашего "направления" - думаю, что большую часть "молодых/да бодрых" вы знаете, но возможно найдете для себя новые интересные имена: ПАПОЧКА.

💡 В математике операций всего две: сложение и дифференцирование, а в финтехе - многА 🤣

Ведь все остальные операции — производные конструкции:
– вычитание = сложение с минусом,
– деление = многократное вычитание,
– умножение = многократное сложение.
Просто и элегантно. Математика любит минимализм.

Но вот ты приходишь в проектирование и тут минимализм уже может подвести.

🤔 Почему?
Потому что если ты решаешь, что у тебя только одна операция — “прибавить сумму”, а знак указываешь внутри (+500 или –500), то на практике легко получить ситуацию:
минус на минус, и ты… внезапно прибавил, когда хотел вычесть.
(Если вы уверены, что вы-то точно такого не допустите, то я вас разочарую! Единственное, что можно гарантировать, это то, что если баг возможен-он случится! Был в моей жизни случай, когда пользователи вышли в ноль из глубокого «долга». Хорошо, хоть не в плюс.)

🔍 В чем проблема?
Система не знает, что операция была кредитная или дебетовая, если ты это явно не сказал.
А знак — не всегда надежный источник истины.

✅ Поэтому в финтехе (и не только) чаще используют другой паттерн:
операция имеет тип, а знак всегда +. credit или debit, а не просто +/-.

🎯 На мастер-классе на ProITFest мы моделировали такую ситуацию на примере компании Lumico. У сотрудников были кристаллики — за обучение, мерч, благодарности коллег.
И вот пришел Вася-архитектор и решил, что типизировать операции не надо. Так система может прожить достаточно долго: или до первого серьезного инцидента с финансовыми потерями, или до необходимости продуктовой разработки.

Вывод:
В математике — минимум операций = максимум строгости.
В проектировании — чем все прозрачнее и очевиднее, тем меньше багов и бизнес-ошибок.

Не всегда меньше — это лучше. Особенно в системах, где деньги.

⚠️NB! Думаю провести бесплатный он-лайн МК по кейсу с ProITFest. Если вам интересно, напишите +, или более развернутый коммент, чтобы я понимала, а надо ли оно…

#fintech #architecture