"The Busy Developers's Guide to Go Profiling, Tracing and Observability"
- https://github.com/DataDog/go-profiler-notes/blob/main/guide/README.md

#Golang

Scott Wlaschin про DDD и FP:
"Domain-Driven Design meets Functional Programming"
- https://blog.avanscoperta.it/2021/09/14/domain-driven-design-meets-functional-programming-scott-wlaschin/

#DDD #FunctionalProgramming #SoftwareDesing

Статистика популярности языков программирования от JetBrains.

"The State of Developer Ecosystem 2021
This report presents the combined results of the fifth annual Developer Ecosystem Survey conducted by JetBrains. 31,743 developers from 183 countries or regions helped us map the landscape of the developer community."
https://www.jetbrains.com/lp/devecosystem-2021/

Может ли одна CQRS-команда изменять несколько агрегатов пакетно? Довольно частый вопрос. Пара статей, которые затрагивают эту тему:
- https://enterprisecraftsmanship.com/posts/ddd-bulk-operations/#command
- https://udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

#DDD #SoftwareDesign

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

> If no one is using your product, who cares how clean your code is?

> This morning your team can add more code, or add more customers. Which do you want?

Эти цитаты вызвали у меня профессиональный интерес, и желание проанализировать их.

Фразы сильно зависимы от контекста. Непонятно, какой опыт от использования продукта (негативный или позитивный), какая модель разработки и обработки неопределенности (BDUF, спиральная, итеративная), какой экономический эффект от раннего выхода на рынок, и предпочтут ли новые пользователи дефектный продукт перед конкурирующим? Попробуем восстановить контекст.

Во-первых, основная задача Clean Code - это повышение темпов разработки. В таком случае, противоречия между первой и второй частями первой цитаты даже не возникает. Если быть точным, то основная задача Clean Code - это достижение архитектурного качества Modifiability, которое позволяет снизить рост стоимости изменения кода вплоть до горизонтальной асимтоты, что создает экономическую целесообразность эмпирического разрешения неопределенности требований путем Adaptation, а не Prediction, поскольку стоимость реализации решения в таком случае становится независимым от момента времени принятия решения. Таким образом, Clean Code представляет ценность не сам по себе, а только как средство достижения экономической целесообразности итеративной модели разработки. Например, при BDUF он уже не имеет такого важного значения, так как все решения уже приняты заблаговременно.

Во-вторых, необретенного клиента еще можно обрести. А вот потерянного клиента вернуть уже достаточно сложно. Из цитаты неясно, какой опыт обретается из "using your product" - позитивный или негативный. А это уже сильно зависит от внутреннего качества продукта.

В-третьих, качество кода не замедляет темпов разработки, потому что существуют методики сглаживания Design Payoff Line.

В-четвертых, существует 4 типа техдолга. При reckless нужно заниматься не Чистым Кодом, а обучением. А prudent часто допускается из соображений YAGNI, кроме случая prudent-inadvertent, который неизбежен, и часто устраняется в контексте Бизнесовых Сторей, так как окупается в пределах релиза. Сам Фаулер в таком случае советует даже ничего не говорить менеджерам.

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

Основная причина появления багов - это высокий уровень сложности, с которым приходится иметь дело краткосрочной памяти разработчика. В таком случае, он легко может упустить что-нибудь из внимания. Еще Гради Буч говорил, что Архитектура - это многоуровневая система абстракций (где назначение абстракций - управление сложностью).

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

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

P.S.: Кто-то красиво сказал - не важно, сколько вы потратили на написание кода, который не работает как нужно.

#SoftwareDesign #Management #SoftwareArchitecture

Подключайся 29 сентября к трансляции Hello Conference!
Neal Ford с темой архитектурные стили и паттерны и другие эксперты в IT архитектуре поделятся своими наработками и опытом.
Мы будем говорить про:
• Архитектуру больших данных;
• Корпоративную архитектуру и практику построения сложных систем;
• Процессы создания верификации архитектуры в аgile проектах;
• Платформы, ArchOps, DataMesh.
И многое другое.
Регистрируйся на сайте helloconf.ru и подключайся 29 сентября к трансляции Hello Conference!
Подробная информация, тайминг и анонсы на сайте helloconf.ru.

What is Domain-Driven Design (DDD)
A definition of DDD as a software design discipline
by Mathias Verraes
- https://verraes.net/2021/09/what-is-domain-driven-design-ddd/

#DDD

Neal Ford и Mark Richards готовят новую книгу "Software Architecture: the Hard Parts"
- https://www.infoq.com/podcasts/software-architecture-hard-parts/

#SoftwareArchitecture

Как-то я пропустил, что Cloud Native Computing Foundation тоже выпускает технологические радары https://radar.cncf.io/2021-09-devsecops

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

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

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

#Psychology #SoftSkills

Пару лет назад проблему удаления персональных данных из неизменяемого Event Sourcing лога событий по требованию GDPR освещал Mathias Verraes, и предложил два подхода:

"Eventsourcing Patterns: Forgettable Payloads. Store the sensitive payload of an event in a separate store to control access and removal." by Mathias Verraes
- https://verraes.net/2019/05/eventsourcing-patterns-forgettable-payloads/

"Eventsourcing Patterns: Crypto-Shredding. Encrypt sensitive information in an event and delete the key." by Mathias Verraes
- https://verraes.net/2019/05/eventsourcing-patterns-throw-away-the-key/

#DDD #EventSourcing #Microservices #SoftwareArchitecture #SoftwareDesign

Проблеме, озвученной Oskar Dudycz, похожее решение дает Mathias Verraes в статье
"Patterns for Decoupling in Distributed Systems: Segregated Event Layers. Explicitly segregate a Bounded Context's events in visibility layers, with their own language."
- https://verraes.net/2019/05/patterns-for-decoupling-distsys-segregated-event-layers/

#DDD #Microservices #DistributedSystems #SoftwareArchitecture #SoftwareDesign

"Getting started with DDD. Definitions of DDD and fundamental concepts to reduce the learning curve and confusion." by DDD-Crew of Nick Tune
- https://github.com/ddd-crew/welcome-to-ddd

"Domain-Driven Design Starter Modelling Process. If you're new to DDD and not sure where to start, this process will guide you step-by-step."
- https://github.com/ddd-crew/ddd-starter-modelling-process

#DDD #Microservices #SoftwareDesign #SoftwareArchitecture

"Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software" by Stefan Hofer, Henning Schwentner
Part of the Addison-Wesley Signature Series (Vernon) series.
- https://www.informit.com/store/domain-storytelling-a-collaborative-visual-and-agile-9780137458912?ranMID=24808

Книга вышла в печать.

#DDD #SoftwareDesign #SoftwareArchitecture #EventStorming #DomainStorytelling

Список всех книг серии Vaught Vernon:
"The Addison-Wesley Signature Series: Vaughn Vernon"
- https://www.informit.com/imprint/series_detail.aspx?ser=7937178&utm_source=product&utm_medium=seriespage&utm_campaign=awss-vernon

#DDD #SoftwareArchitecture #SoftwareDesign

Тут в чате канала @webkunx подсказывает, что вышел полноценный релиз второго издания "Building Microservices: Designing Fine-Grained Systems" by Sam Newman (September 28, 2021):
- https://www.amazon.com/gp/product/1492034029

Ранее был доступен early release raw & unedited.

Все новинки Software Design & Engineering:
- https://www.amazon.com/gp/new-releases/books/491316/ref=zg_b_hnr_491316_1

Из них две книги by Vladik Khononov ( @vladik_kh ).

P.S.: Если вдруг кто-то не знал - задать ему вопрос можно в чате канала.