"Software Design: Tidy First?" - новая книга, над которой работает Kent Beck. Читать главы можно уже сейчас:
- https://tidyfirst.substack.com/archive?sort=new

#SoftwareDesign

Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.

Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?

Btw, коллекция (почти) всех гайдов одним архивом:

TOGAF® Series Guide Full Set

This is the set of TOGAF® Series Guides. They contain detailed guidance on how to use the TOGAF framework, and are expected to be the most rapidly developing part of the TOGAF documentation set.
- https://publications.opengroup.org/guides/togaf/togaf-series-guides/t180

#SoftwareArchitecture

"Data Mesh" by Zhamak Dehghani

Released April 2022
Publisher(s): O'Reilly Media, Inc.
ISBN: 9781492092391

https://www.oreilly.com/library/view/data-mesh/9781492092384/

#SoftwareArchitecture

Когда спрашивают зачем нужен слой абстракции от БД:

❌ФСТЭК отзовет более 50 продуктов иностранных разработчиков, которые приостановили свою деятельность в России

— Приостановлены сертификаты на решения от IBM, Microsoft, Oracle, SAP, Vmware, ESET, Trend Micro и другие.

— Действие сертификатов будет прекращено, если компании не возобновят поддержку продуктов в течение 90 дней.

— Теперь государственным информационным системам и объектам критической информационной инфраструктуры придётся ещё быстрее искать замену зарубежным системам.

https://www.securitylab.ru/news/530814.php?r=1

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

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

Существуют некоторые вещи, которые являются ключевыми. Профессиональная задача архитектора - эти вещи выявлять.

📝 “Architecture is about the important stuff. Whatever that is” - Ralph Johnson

[Здесь шла речь о принципе, который со времен Гераклита используется для разрешения противоречий.]

Такие же принципы существуют и в архитектуре, и одним из монументальных принципов является Constantine's Law: "Low Coupling & High Cohesion". Однако, знание этого принципа еще не гарантирует его успешной практической применимости, также как и знание букв еще не делает человека поэтом. Потому что, как говорил Edsger W. Dijkstra:

📝 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." — Edsger W. Dijkstra

В своей практике я иногда замечал, как программисты могут "переусложнить" решение, не утруждаясь осознанием тонкой грани между простотой и примитивностью. Различие между этими терминами проявляется позже, когда становится очевидным, что краткосрочные интересы препятствуют долгосрочным интересам, а не служат им. И тогда проект, подобно Уроборосу, удерживает себя за хвост своего собственного развития. Это явление иногда ошибочно путают с YAGNI.

Колоссальный монументальный труд в исследовании вопроса управления сложностью проделал Vlad Khononov - человек, обладающий уникальной способностью объяснять сложные вещи простым языком. Очень скоро его книга "Balancing Coupling in Software Design: Successful Software Architecture in General and Distributed Systems" станет доступной в продаже. Книга номер один среди всех существующих руководств по созданию успешного проекта. Книга, которая не захламляет, а очищает и кристаллизует знания, учит управлять образом мышления, и вооружает нас принципом, способным легко отыскивать победные решения в задачах любого уровня сложности. Книга, которая станет достойным продолжением дела Larry Constantine, Tom DeMarco, Meilir Page-Jones, David L. Parnas, Robert C. Martin.

Неплохое руководство по управлению сложностью:

- https://www.youtube.com/watch?v=LKtk3HCgTa8

В текстовом виде:
- https://github.com/matthiasn/talk-trannoscripts/blob/master/Hickey_Rich/SimpleMadeEasy.md

Thanks to @vault13dweller

"Series of articles about functors, applicatives, and other mappable containers." by Mark Seemann
- https://blog.ploeh.dk/2018/03/19/functors-applicatives-and-friends/

#FunctionalProgramming

Сейчас в кулуарах российского архитектурного сообщества обсуждается вопрос организации Reference Application и Reference Architectures.

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

Пример DDD/MSA Reference Application:
- https://github.com/dotnet-architecture/eShopOnContainers

Пример Reference Architecture:

"Agile Architecture Modeling Using the ArchiMate® Language":
- https://publications.opengroup.org/g20e
- https://nicea.nic.in/sites/default/files/Agile_Architecture_Modelling_Using_Archimate.pdf
- https://community.opengroup.org/archimate-user-community/home/-/issues/8

Archi Banking Group: Combining the BIAN Reference Model, ArchiMate® Modeling Notation, and the TOGAF® Framework:
- https://publications.opengroup.org/y201
- https://publications.opengroup.org/y201m

И т.п.

Я нередко использую Reference Applications в работе, для демонстрации типовых архитектурных решений разработчикам. Могу заметить, что полностью завершенные эталонно-демонстрационные приложения мне неизвестны, поэтому, приходится обращаться к ним в качестве демонстрационных примеров разрозненно и фрагментарно, "выкусывая" из них качественно организованные аспекты и игнорируя остальные. У меня даже сформировался некий "путеводитель", указывающий в каком демонстрационном приложении лучше смотреть реализацию того, либо иного, архитектурного аспекта.

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

Если кому эта тема интересна, и кто-то хочет её обсудить, и имеет возможность принять участие в создании Reference Application/Architectures, обращайтесь ко мне в личку ( @emacsway ) за инвайтом в группу обсуждения. Вместе попробуем найти решение этого вопроса.

Коротко о самой сути термина Technical Debt:

📝 "Asking "is something technical debt" is usually uninteresting. The metaphor's value is comparing paying interest vs principal. We judge debt of $1K differently if we are paying $1/month to service it vs $100/month"

-- Martin Fowler, https://twitter.com/martinfowler/status/1517152168775614473?t=BMpST8vXSLBnY36k9o-lUg&s=19

Подробнее по этой теме здесь.

"Modeling Relationships in a DDD Way" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/modeling-relationships-in-ddd-way/?__s=dqpdv6io8bhfhi1pm82y

Хорошая статья, но самый интересный вопрос остался неосвещенным:

> The problem is that it’s hard to decide which side of a many-to-many relation is the owner of that relation.

#DDD #SoftwareDesign

"Multi-cloud: From Buzzword to Decision Model" by Gregor Hohpe
- https://architectelevator.com/cloud/multi-cloud-decision-model/

Architects aren’t there to make all decisions. They help others make better decisions by sharing models. Let’s do that for a major enterprise decision: whether to cloud or multi-cloud.

📝 "Architects aren’t the smartest people in the room. Their primary job is to make everyone else smarter, for example, by getting folks to see more dimensions."

Хорошая статья.

#SoftwareArchitecture

Мне приходилось слышать о ряде неудачных кейсов по внедрению DDD. Интересно послушать ваш опыт внедрения DDD. Был ли он успешным? Каким образом удалось преодолеть сопротивление? Был ли он неудачным? По каким причинам?

"Gregor’s Law" by Gregor Hohpe

Excessive complexity is nature’s punishment for organizations that are unable to make decisions.
- https://architectelevator.com/gregors-law/

#SoftwareArchitecture