Эта картинка прекрасна. В ней есть источник света (ученье - свет), передовые средства навигации (облегчение навигации в обширной области знаний - одна из ключевых наших целей) и сама необъятность просторов.

Ну и центр притяжения Земли, обеспечивающий орбиту своих спутников - роль которого и должно выполнить наше объединение 🙂))

🔷 "Event Sourcing explained" - The internet contains many confusing articles that mix Event Sourcing with EDA and CQRS. Let’s see what it is and what not.
by Anton Stöckl - автор проекта go-iddd - Golang DDD CQRS/ES Reference Application

#DDD #EDA #CQRS #EventSourcing #SoftwareDesign

🔷 "Using scenarios to reinvigorate your microservice architecture" by Chris Richardson

It sounds dull but good architecture documentation is essential. Especially when you are actively trying to improve your architecture. For example, I spend a lot time helping clients modernize their software architecture. Yet more often than I like, I’m presented with a vague and lifeless collection of boxes and lines. As a result, it’s sometimes difficult to discuss the architecture in a meaningful and productive way.

In this presentation, I’ll describe techniques for creating minimal yet effective documentation for your application’s microservice architecture. In particular, you will learn how documenting scenarios can bring your architecture to life.

#Microservices #Documenting #SoftwareArchitecture

🔷 "The Process Automation Map" by Bernd Reucker
🔷 "Exploring the Process Automation Map" by Bernd Reucker
Как раз недавно поднимался вопрос по этой теме в чате канала.

#SoftwareArchitecture

🔷 "Concerned about Serverless Lock-in? Consider Patterns!" by Gregor Hohpe

Design patterns have long been a useful tool for designing software. Several decades later, they can do magic for your solutions by not only improving your designs but also by reducing switching costs.

#SoftwareArchitecture #DistributedSystems

🔷 "10 problems that Event Sourcing can help solve for you" by Dennis Doomen

#DDD #CQRS #EventSourcing #SoftwareDesign

Интересное ежегодное исследование от компании Positive Technologies в мире информационной безопасности.
Тренды, аналитика, события. Отвлекитесь и полистайте на выходных =)
https://www.ptsecurity.com/ru-ru/research/analytics/positive-research-2022/

Software engineering and systems engineering - связь этих дисциплин и стандарт The Software Engineering Body of Knowledge

Программная инженерия и системная инженерия — не просто связанные дисциплины; они тесно переплетены. Правильная системная инженерия является ключевым фактором в деле построения качественной разработки программного обеспечения.

"Software engineering and systems engineering are not merely related disciplines; they are intimately intertwined. (See Systems Engineering and Other Disciplines.) Good systems engineering is a key factor in enabling good software engineering.

The SEBoK explicitly recognizes and embraces the intertwining between systems engineering and software engineering, as well as defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK) (Bourque, and Fairley 2014)."
https://www.sebokwiki.org/wiki/Systems_Engineering_and_Software_Engineering

SWEBOK - это стандарт
ISO/IEC TR 19759:2015
Software Engineering — Guide to the software engineering body of knowledge (SWEBOK): https://www.iso.org/standard/67604.html

Здесь обзор текущей версии SWEBOK (v3): https://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide#Knowledge_Areas_Characterizing_the_Practice_of_Software_Engineering

А здесь можно скачать SWEBOK v3:
https://www.computer.org/education/bodies-of-knowledge/software-engineering

А вот здесь SWEBOK v3 на русском: https://github.com/ligurio/swebok-2004-in-russian

Драфт новой версии SWEBOK (v4): https://waseda.app.box.com/v/ieee-cs-swebok

Крис Ричардсон опубликовал ссылку на весьма примечательное исследование.

Цитирую его:
"Unsurprisingly, technical debt impacts business outcomes.
Research by @AdamTornhill found that organizations waste up to 42% of their time due to technical debt."
https://www.researchgate.net/publication/359129462_Code_Red_The_Business_Impact_of_Code_Quality_--_A_Quantitative_Study_of_39_Proprietary_Production_Codebases

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

Коротко напомню о том, что такое Agile SDLC-model - это итеративно-инкрементальная модель разработки, на которую наложен ряд филосовско-психологических принципов с целью снизить напряжение между техническими специалистами и представителями бизнеса.

Основой этой филосовско-психологической прослойки стал документ Bill of Rights, который является результатом глубокого аналитического труда Kent Beck в области психологии. Дело в том, что Kent Beck имел превосходную эрудированность в области психологии, философии и менеджмента, а морально-психологический климат в ИТ-индустрии того времени был, мягко говоря, напряженным. Кстати, мы этот документ уже упоминали.

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

Идея Bill of Rights возникла на основе идеи Declaration of Independence (перевод):

💬 "Software development is risky. People involved have many fears of what may go wrong.

To develop effectively we must acknowledge these fears. Why do we need a software process? For the same reason that we need laws, governments, and taxes: fear.

The Declaration of Independence says:

That among these [rights] are life, liberty, and the pursuit of happiness. That to secure these rights, governments are instituted among men, deriving their just powers from the consent of the governed.

Though the profundity of these words may distract us, consider the word secure. We institute governments because we are afraid of losing our rights. By the same token, we institute software processes because we are afraid."
-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

Однако, вернемся к инкрементально-итеративной основе Agile-модели. Основная решаемая ею проблема - это разрешение неопределенности требований эмпирическим способом (т.е. опытным путем, широко известным как "метод научного тыка"), что повлекло смещение фокуса архитектуры с предвидения развития системы на её изменяемость, т.е. на такие методы разработки, которые позволили бы вести реализацию системы в условиях недостаточной полноты требований, максимизируя таким образом количество открытых решений, где их открытость обеспечивается низкой стоимостью их изменений. Разумеется, без фанатизма, сохраняя баланс.

В превосходной статье Craig Larman "Iterative and Incremental Development: A Brief History" говорится о том, что цикл PDSA известен еще с 1930 года, в 1957 году впервые была применена инкрементальная модель разработки, а в 1968 году - итеративная.

И вот теперь мы подошли к интересному вопросу, который рассмотрим далее. Почему при столь высокой практической востребованности, эмпирический способ разрешения неопределенности в виде итеративной модели впервые получил практическое применение лишь в 1968 году, а начал обретать массовость лишь в конце 1990-х годов?

#SDLC #Agile

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

На изображении из книги "Extreme Programming Explained" 1st edition by Kent Beck приводится типичный график роста стоимости изменения кода в зависимости от момента принятия решения, характерный для времён до 1990 года. Из данного графика возникает экономическая целесообразность принимать решения как можно раньше, стремясь к моменту наименьшей стоимости их реализации. Это создает экономическую целесообразность заблаговременной обработки неопределенности, вплоть до BDUF, который, как известно, является моментом наименьшей информированности:
https://t.iss.one/ru_arc/50

#SDLC #Agile

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

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

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

Как можно разрешить этот "Catch-22"? Согласно "Первому закону диалектики", противоречие должно привести к синтезу, т.е. к качественному изменению.

И решение этого противоречия схоже с решением противоречия "Закона Брукса", в виде автономных команд. Или же с решением в виде Bounded Context, которое разрешает противоречие, заключающееся в том, что при стремлении выровнять язык по всей модели, он стремится к противоречивости (и неоднозначности). Т.е. стремление следовать предметной области вынуждает отступать от неё. В нашем случае решение так же заключается в разбиении целого (процесса разработки) на части (итерации), только вместо согласованности единого языка здесь критерием разделения выступает достаточность полноты требований.

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

Скачкообразное изменение состояния называется в философии "революцией" (коренной смысл этого термина далек от политики), и именно на это намекает заголовок статьи "The Winter Getaway That Turned the Software World Upside Down" By Caroline Mimbs Nyce - одного из участников встречи 2001 года по Agile Manifesto.

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

#SDLC #Agile

Пообщались на Flow Live про архитекторов и архитектуру. Целевая аудитория стрима – аналитики, соответственно и спич с этой позиции.

Область системного анализа довольно близка к разработке архитектуры. Случается, что роль архитектора выполняет разработчик или лид системный аналитик. А бывает и наоборот. На проекте нет штатного архитектора. Или он есть, но настолько занят, что его как бы и нет. И вот в этом случае как раз и пригодятся знания о том, как разрабатывать архитектуру, как предусматривать такие моменты развития системы, про которые разработчик и системный аналитик никогда не задумывались. В этом подкасте разговариваем про архитектуры и почему в них важно разбираться системному аналитику. А также про то, кто такие архитекторы.

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

FIGURE 3.8 Historical cost of exploration.

-- "Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth Rubin, "Chapter 3 Agile Principles :: Prediction and Adaptation"

График демонстрирует те самые "количественные изменения", которые привели к изменениям качественным.

Обрели массовость высокоуровневые объектно-ориентированные языки с уклоном на управление сложностью, появились шаблоны и принципы проектирования, методики управления сложностью (ROM, POSA, GOF, OOAD, SOLID, Use Case Driven Approach, Object-Oriented Software Construction etc.), появились TDD, Refactoring и т.п.

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

С точки зрения диалектики, смена превалирующей на рынке модели разработки с каскадной на итеративную была ожидаемой и неизбежной.

#SDLC #Agile

🔷 "Layers, Onions, Ports, Adapters: it's all the same" by Mark Seemann

Статья не нова, но отвечает на частые вопросы.
#DDD #SoftwareDesign

Делюсь презентацией из доклада с ArchDays 2022.
#SAGA #ArchDays

В прошлую пятницу прошла конференция ArchDays.

На мой взгляд конференция прошла отлично. Выступения интересные и глубокие.

Мы постарались максимально обыграть онлайн участие, отстроить звук, поставили экраны покрупнее, закупили попкорн и колу 🙂

Все презентации доступны по ссылке: https://archdays.ru/program/

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

Огромная благодарность спикерам, участникам, нас было 250 человек очно и 270 человек онлайн.