emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. – Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
3.48K subscribers
119 photos
15 videos
22 files
1.14K links
Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, Extreme Programming, SDLC, Agile, etc.

Chat: https://news.1rj.ru/str/emacsway_chat

Persistence: https://dckms.github.io/system-architecture/
Download Telegram
Forwarded from Igor Nikolskii
Доброго времени суток, многоуважаемый IT-ALL.
Хочу вам рассказать об IT-активности государства в предметной области Экология и Природопользование.
Была создана Рабочая Группа (РГ), которая включает в себя экспертов как в IT, так и Экологии и природопользовании.
Всем нам хочется жить экологично, есть экологичные продукты, отдыхать в чистоте на природе и посещать заказники, заповедники и национальные парки, а может и порыбачить или поохотиться.
Как IT-шникам нам безусловно интересна активность государства в Цифровизации страны, и мы предлагаем принять в ней непосредственное участие.
Кому-то интересно, а как зоопарк наследованных систем (legacy) специалисты с интегрируют в единую систему.
Кому-то интересно, какие технологии проектирования будут использованы.
Кто-то из вас обязательно поднимет вопрос об едином инструментарии SDLC/Devops pipeline.
Кого-то увлечёт вопрос, а что будет использоваться в начинке – containerd или не трендовый docker.
Кто-то начнёт топить за развёртывание будущей системы на Debian 11, кто-то сильный в информационной безопасности будет настаивать на CentOS
А кто-то просто решит не участвовать в опросе и скажет, что всё будет как всегда.
Многоуважаемое IT-сообщество, давайте поможем государству сделать правильно!

Ссылка на опрос с просьбой от РГ:

Дорогие друзья!
Началась работа по созданию экосистемы цифровых сервисов в сфере экологии и природопользования для каждого из нас. В режиме «одного окна» будет обеспечена реализация необходимых услуг, которые позволят нам использовать природные ресурсы, сохранять и заботится об окружающей среде.
Большая команда экспертов изучает жизненные ситуации и потребности, которые возникают у каждого из нас в сфере экологии и природопользования. Нам ОЧЕНЬ ВАЖНО узнать именно Ваше мнение о том, с какими сложностями Вы сталкиваетесь в различных жизненных ситуациях, связанных с экологией и природопользованием. Ответив на вопросы анкеты Вы поможете сделать цифровые сервисы по-настоящему удобными и простыми в реализации.
Для удобства мы составили опрос, который не займет больше 20-30 минут Вашего времени. Сделайте свой уникальный вклад в проектирование будущей цифровой экосистемы страны – домена «Экология и природопользование».
Пройти опрос можно в любое время до конца дня 8 июня 2022 года по ссылке:
https://forms.yandex.ru/u/6298d927750e717d4886c046/.
👍5😁1
Мы решили объединить усилия в новом коллективном телеграм-канале, посвященном вопросам ИТ-архитектуры и управления процессами разработки.

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

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

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

Существующий телеграм-канал продолжает оставаться моим личным каналом, но значительная часть ценного контента будет публиковаться уже в новом, объединённом канале. Подписывайтесь: https://news.1rj.ru/str/ru_arc

Канал самоуправляется консенсусом коллегии из четырех человек: @sergey486 , @GKruglov , @elukianov и я. Круг авторов этим не ограничивается. Если вы поддерживаете наши устремления и обладаете необходимыми навыками, то можете пополнить наш авторский коллектив (обращайтесь к любому из списка).

Для обсуждений создан чат: https://news.1rj.ru/str/ru_arc_chat

Это только первый шаг. Уже сейчас мы продумываем принципы, которые позволят коллективизировать работу над архитектурными руководствами, а так же над Reference Architectures/Applications. Есть и другие идеи, но о них говорить пока еще преждевременно. В общем, должно получиться интересно.

#Goal
👍15👎1
Как и у всех остальных коллег, систематически светящихся зеленым значком "online" в три часа ночи, у меня была многолетняя вредная привычка не спать по ночам. Да, я знал, что это вредно, знал про специфику выработки мелатонина, но, при таком "содействии" коллег, я не мог побороть эту привычку аж до тех пор, пока не купил себе смарт-часы Huawei Watch 3 Pro. Вообще-то, я всегда был фанатом "механики", но тут покупал новый смартфон, и мне предложили взять к нему еще и часы. Взял. И каждое утро они мне стали присылать отчет сна: во сколько заснул, сколько спал, какую часть сна составила глубокая фаза и т.п. Через пару недель такого регулярного "капания на мозги" я не выдержал и начал избавляться от этой вредной привычки. Еще и стал чаще ходить на прогулки, т.к. каждый раз, когда смотрю время, вижу количество пройденных шагов. А для нормального поддержания сердечно-сосудистой нужно каждый день проходить не менее 5 км.
👍14
Групповое мышление (Groupthink) — психологический феномен, которому многие подвержены, но о котором немногие подозревают. Он объясняет, почему групповое решение вовсе не обязательно приводит к сбалансированному, взвешенному и правильному решению.

Пара неплохих статей на ресурсе Atlassian о роли когнитивных искажений в Decision-Making:

- "5 cognitive bias examples and how to avoid them in decision-making"

- "Reading this decision-making article is the best decision you’ll make today"

Интересно то, что автор затронул одну из наиболее острых тем "Think through short-term and long-term effects". На эту же тему писал Craig Larman в статье "Системное мышление".

В общем, в нашу эпоху Team First Architecture, психология стала неотъемлемой частью архитекторской работы.

На всякий случай, шпаргалка по когнитивным искажениям в виде мобильного приложения - вдруг кому пригодится:
- https://play.google.com/store/apps/details?id=ru.free_coding.biascs

#Psychology
🔥4🤔1
На Snowbird meeting обсуждались принципы "Bill of Rights", один из которых гласит:

📝 "You [programmer] have the right to produce quality work at all times."

Причем:

📝 "During the Snowbird meeting, Kent Beck said that the goal of Agile was to heal the divide between business and development."
-- "Clean Agile: Back to Basics" by Robert C. Martin - организатор той встречи.

Недавно состоялся опрос, по результатам которого выяснилось, что 20% участников опроса демотивированы загниванием кода по причине отсутствия понимания со стороны Product Owner (Project Manager). Эту проблему хорошо освещали многие известные авторы: Kent Beck, Robert Martin, Jeff Sutherland, Martin Fowler, Craig Larman, Henrik Kniberg, Dean Leffingwell, Kenneth Rubin, Ward Cunningham и другие.

Как могло получиться, что, используя Agile, разработчики, вместо "produce quality work at all times", вынуждены копаться в коде, который по своей консистенции не сильно отличается от свалки? Терпения на такие "условия работы" хватает не у всех, что является одной из распространенных причин текучки кадров.

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

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

Знакома ли вам эта проблема? Удалось ли её решить? Каким образом?

#SoftwareDesign #SDLC
🔥7👍4
"Help geeks feel safe in the world" - карьерная миссия Kent Beck очень близка целям нашего объединения. На прошлой неделе он посвятил этому вопросу целую статью: "Help Geeks Feel Safe In The World: My Personal Mission".

Роль Kent Beck в индустрии сложно переоценить: Design Patterns, xUnit, TDD, Refactoring, Extreme Programming и существенное влияние на Agile Manifesto. Невероятно эрудированный человек, обладающий редкой способностью объяснять сложные вещи простым языком.

#Goal
🔥4👍2
Мы продолжаем информировать вас о целях нашего объединения, поскольку, как говорится, важно не объединение само по себе, а те принципы, на которых оно основано. Сообщения о наших целях мы будем помечать тегом #Goal .

Как говорил Gregor Hohpe:

"There's a definite Dunning-Kruger effect for authors.
The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special".
Then you have people who write a lot but do little real work that they could base their writing on..."


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

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

Наш принцип: практикующий специалист имеет право на легкий доступ к качественной информации. И это право не должно ущемляться правом других на свободу распространения информации.

#Goal
👍11🔥4
Forwarded from Russian Association of Software Architects (Gennadiy Kruglov)
Это ресурсы для 1-ой очереди изучения, то есть базовые, необходимые в первую очередь.

В перечне только актуальные и "свежие" ресурсы, за исключением (древней) книги Эванса по DDD. Эта книга по-прежнему полностью актуальна

Блоги:
https://martin.kleppmann.com/
https://berndruecker.io/
https://architectelevator.com/

Каталоги паттернов:
https://www.enterpriseintegrationpatterns.com/
https://microservices.io/

Базовые знания:
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable-ebook/dp/B06XPJML5D/
https://www.amazon.com/Balancing-Coupling-Software-Design-Addison-wesley/dp/0137353480

DDD:
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/
https://www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131/

Микросервисная архитектура:
https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543/

Workflow Management:
https://www.amazon.com/Practical-Process-Automation-Orchestration-Microservices/dp/149206145X/

Исследование предметной области:
https://www.eventstorming.com/

Архитектурные фреймворки:
https://pubs.opengroup.org/architecture/o-aa-standard/

Методологии разработки и орг архитектура:
https://teamtopologies.com/

Важнейшие статьи:
https://martinfowler.com/articles/architect-elevator.html
https://martinfowler.com/bliki/MonolithFirst.html
https://martinfowler.com/bliki/SacrificialArchitecture.html
👍17🔥2
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
В последнее время многие обсуждают DDD, но не все понимают что это такое. От этого страдает качество подобных обсуждений. И найти внятное определение DDD в литературе, действительно, непросто. Ниже приводится определение DDD от первоисточника:

I. Putting the Model to Work

Domain-­Driven Design is an approach to the development of complex software in which we:

1. Focus on the core domain.
2. Explore models in a creative collaboration of domain practitioners and software practitioners.
3. Speak a ubiquitous language within an explicitly bounded context.

This three-­point summary of DDD depends on the definition of the terms, which are defined in this booklet.
Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling. Taken together, they lay out a quite different approach to modeling and software development that runs from fine details to high-­level vision. Rigorous modeling conventions must be balanced with free exploration of models in collaboration with non-­technical people.
Tactics and strategy must be combined to succeed, and DDD addresses both tactical and strategic design.

-- "Domain-Driven Design Reference" by Eric Evans

#DDD
👍4🔥2
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Читал на днях книгу Alberto Brandolini "Leanpub: Introducing EventStorming", где он говорит о распространенной ловушке моделирования агрегатов, когда на него возлагают функции Read Model:

📝 "A shopping cart will include the list of the items to be purchased, with the associated quantity and price.

Bread and butter, apparently, except that we now should be asking ourselves whether we need to include the ItemDenoscription in the ItemInCart. Feels like we should, because we’ll need to display the ShoppingCart info to the customer, in order to review the cart before proceeding to checkout “is this really the stuff you intended to buy? Have you looked at the grand total?”. Things might get awkward when starting to consider events like ItemPriceUpdated or ItemDenoscriptionUpdated, that should have us thinking whether we should include a copy of the entire denoscription of the selected item, or just a reference to the Item in stock.

Hmmm… not. Sorry for the detour, but these are not the aggregates we’re looking for. “data to be displayed to a user in order to make a decision” will be a Read Model. Aggregates are something else, but we have to be aware of this vicious temptation of superimposing what we need to see on the screen on the internal structure of our model."
-- "Leanpub: Introducing EventStorming" by Alberto Brandolini

#DDD #Microservices
👍4🔥2