"Back from the engine room. Architects dive deep to come back up with new insights. Here’s is what I brought back from the serverless cloud integration engine room." by Gregor Hohpe
- https://architectelevator.com/architecture/engine-room/

#EIP #SoftwareArchitecture

"Domain-Driven Refactoring: Encapsulating Data" by Jimmy Bogard
- https://jimmybogard.com/domain-driven-refactoring-encapsulating-data/

#SoftwareDesign #Refactoring #DDD

Парень продолжает переводить архи-полезные и архи-актуальные статьи. На этот раз, он перевел ряд статьей Володи Хорикова ( @vkhorikov ). Перечислять все не буду, дам ссылку на список его последних постов:
- https://habr.com/ru/users/ArkadiyXIII/posts/

#DDD #TDD #Testing #FunctionalProgramming

Максим Аршинов о кроссфункциональности разработчиков:
"Фулстеки — это будущие архитекторы, а не вечные мидлы (если захотят конечно)"
- https://habr.com/ru/post/575118/

#Agile

"The Specification contravariant functor by Mark Seemann"
- https://blog.ploeh.dk/2021/09/09/the-specification-contravariant-functor/

"Contravariant functors" by Mark Seemann
- https://blog.ploeh.dk/2021/09/02/contravariant-functors/

"The Reader functor" by Mark Seemann
- https://blog.ploeh.dk/2021/08/30/the-reader-functor/

"The Command Handler contravariant functor" by Mark Seemann
- https://blog.ploeh.dk/2021/09/06/the-command-handler-contravariant-functor/

#FunctionalProgramming

"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