DDDevotion

Спам достал, решил по совету @irrationality попробовать предбанник. Посмотрим как с ним будет.

Какое хорошее сравнение!

Я всегда стараюсь подсветить продактам и разработчикам, если часть айтемов в беклоге уже давно покрылась плесенью. Особенно "люблю" статусы а-ля PAUSE или WAITING.
Почему для инженеров в продуктовой команде важен чистый (дистиллированный) бэклог?

Оказывается видео Эванса уже доступно (с другой конфы)

Эрик поделился своим взглядом на развитие LLM и их потенциал. Доклад местами капитанский, если вы последние год-два хоть что-то копали по этой теме.
Что важно, если коротко: 1. будущее непредсказуемо, 2. надо экспериментировать с LLM уже сейчас.

https://www.youtube.com/watch?v=Tll_suxZluk

Поделитесь вашими инсайтами 🙏

Прикольное упражнение, заряжаем в GPT промпт "Describe the domain, model of which consists of classes:" и далее copypaste список классов из модели домена. Оно вываливает кучу текста, похожего на правду, если вы используете термины из предметной области, а затем "provide clear and brief description" и в догоночку "Provide bounded context name based on description" и мэтчим с собственным названием ограниченного контекста :) Не то, что бы я открыл кейс для использования LLM, просто оно неплохо справляется в части "naming things", уже не первый раз дистиллирую термины и это работает.

Почему агрегаты должны хранить свои секреты

Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).

Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:

Сохранение секретов == гибкость

Когда агрегаты скрывают свою внутреннюю структуру, наша система становится гораздо более гибкой. Вы можете рефакторить внутрянку, не переживая за другие части кодовой базы. Внешние компоненты взаимодействуют с агрегатами через четко определенный интерфейс (aggregate root, корень агрегата), что делает наш код более устойчивым к изменениям.

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

Не DDD единым
Утомился от споров про ивент шторминг, cqrs, границы контекстов? Устал перемапливать джейсоны? Хочется копаться в кишочках?

Новый сезон курса по базам данным от Andy Pavlo ждет тебя! Только с++, только хардкор!

https://www.youtube.com/watch?v=otE2WvX3XdQ

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

С Днём знаний! Вперёд к новым вершинам! 🚀

Друзья из Health Samurai проводят 8 августа архитектурный митап: про модели, cqrs — всё что мы любим 💪

Всем привет!
Самураи организуют онлайн-митап по архитектуре систем и кода. Мероприятие состоится 8 августа в 17:00 (Por). Поделимся нашими инсайтами, опытом и хотим послушать вас :)

Будет 2 доклада по 25 минут и время на вопросы и обсуждение:
🔉 Системы движимые моделями
— Николай Рыжиков, CTO at Health Samurai
🔉 CQRS в действии
— Артем Бурыкин, Founder at AVE Systems

Приглашаем опытных инженеров и архитекторов. Участие бесплатное, необходима регистрация!
Подробности про мероприятие 👉 здесь

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

Я не буду писать почему закомментированный код это плохо. Давайте разберемся откуда берется закомментированный код и каковы причины.

Первый вариант. Была реализована некоторая функциональность, которая теперь не нужна. Что делает разработчик в рамках новой таски? Правильно, комментит код! Почему он выбирает такой путь?

- Так проще! И на самом деле при большом давлении сроков мы выбираем здесь и сейчас не самые оптимальные решения.
- Разработчик не уверен в решении. Мы комментим, запускаем код, оцениваем результат глазами или через тесты. Если нет результата - комментим что-то другое, раскомменчиваем пока не получим нужное поведение. Получили? Льем в репу, ведь (см. пункт первый) так проще!
- Разработчик не верит продакту/аналитику/постановщику задачи. У многих был опыт когда фичу требовали вернуть. И проще просто раскомментить нужный кусок, чем что-то делать средствами гита.

Второй вариант. Мы что-то сделали в рамках большой фичи, но некоторая малая часть не получила пока что аппрув. Вот этот кусочек и комментим для прекрасного будущего. Причины, в целом, те же самые: когнитивный перегруз, давление дедлайнов, поломанная коммуникация с продактом, недоверие коду, нехватка практики с гитом, фича-флагами и тп.

Третий вариант, который приходит в голову - копипаста чужого кода и отсекание комментами всего ненужного (почувствуй себя великим скульптором!). Но по большей части этот вариант сводится к первым двум.

Что же делать? Можно пообещать разные кары и периодически публично высмеивать коллег. Можно настроить проверки в гите и реджектить такие коммиты. Но это борьба с последствиями. И она может только частично замаскировать существующие проблемы.

Попробуем повлиять на причины.

Инструментарий.
Не все знают гит в совершенстве. И в этом нет ничего стыдного, ведь почти всю работу с гитом сейчас забрали IDE. Но можно регулярно рассказывать на внутренних митапах и прикапывать полезные команды и подходы в базе знаний. Нет митапов и базы знаний? Заведите, это очень полезные практики.

Коммуникация с продактом.
Зачастую у нас нет прямого влияния на продакта. Но есть способы которые мне помогали: обратная связь, коучинг и обучение. Да, вы можете развивать вашего продакта, учить его, наставлять. Хорошие продакты готовы принимать новое и не воротят нос, если вы с ними разговаривает не на языке красоты кода, а объясняете влияние тех или иных решений на систему.

Давление сроков.
Уже много раз писал, что жесткие дедлайны портят код. Как бы умные дядьки типа Фаулера не убеждали нас, что качественный код писать быстрее и дешевле, под давлением сроков многие из нас выберут срезать углы здесь и сейчас (и получить даже за это квартальную премию), хоть суммарно это и приведет к удорожанию поддержки и разработки. Старайтесь избегать дедлайнов там где это возможно. Если вы даете примерную дату релиза, то убедитесь, что все воспринимают это именно как прогноз, а не дедлайн. Если ваш продакт или проджект менеджер привык к ковровым дедлайнам - расскажите про последствия, можно с примерами из вашей кодовой базы.

Неуверенность в решении.
Что нам дает уверенность в нашем решении? Компилятор, юнит-тесты, автотесты, регресс, телеметрия с прода, продуктовые метрики и иной фидбек. Чем быстрее мы можем получить обратную связь, тем более мы уверены в нашем коде. Инвестируйте в автотесты, практикуйте TDD, BDD, Test-First и другие подобные практики. Также нам поможет правильная нарезка на модули-сервисы, снижение coupling, единая ответственность и другие подобные подходы.

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

А как у вас?

const ABCTwoSomeText: React.FC<ABCTwoSomeTextProps> = ({ softName }) => {
return (
<>
<Text size="small" className="mt10x">
<Trans i18nKey="some:abc->abcTwo->access" values={{ softName }} />
</Text>
=========> {/* Will be useful in the future */}
{/* <Text size="small">
<Trans i18nKey="some:abc->abcTwo->accessDate" values={{sfotName, date: moment(date).format("DD.MM.YYYY")}} />
</Text> */}
</>
);
};
export default ABCTwoSomeText;

У Марка Ричардса свой DDD, с демонстрацией и дискуссией 😅

Отличное завершение дня. Брандолини - топ 🔥

Если будет преза - обязательно скину.

Фанаты беснуются! Хедлайнер вечера на сцене🔥

Эти правила сделают ваш код чище и лучше. Не всегда получится их выполнить, да и не всегда стоит. Но попробуйте вспомнить эти правила в следующий раз и задать вопрос: «а что если…»

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

Сегодня начались доклады на DDD Europe 2024. Первый день называется DDD foundation. Доклады по достаточно базовым вещам - но надеюсь услышать что-то полезное энивей.

Я пропустил первый доклад от Майкла Физерса и сейчас слушаю про транзакции, легаси и прочее. Stay tuned 🤙