Выглядит неплохо. Заслуживает внимания.
Architecture Playbook
https://nocomplexity.com/documents/arplaybook/index.html

#SoftwareArchitecture #SoftwareDesign #Microservices

Перевод монументальной статьи "Is Design Dead?" by M.Fowler о том, как избежать крайностей в архитектуре приложения при Agile разработке: http://citforum.ru/SE/project/design_dead/

#SoftwareDesign #SoftwareArchitecture #Agile

"The Architect’s Path (Part 2 - Implementation)" by Gregor Hohpe
https://architectelevator.com/architecture/architect-bookshelf/

#SoftwareArchitecture #Carrer

"Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model" by Nick Tune
- https://medium.com/nick-tune-tech-strategy-blog/team-responsibility-ownership-patterns-part-1-a-business-architecture-model-63597c4e60e1

"Architecture Ownership Patterns for Team Topologies. Part 2: Single Team Patterns" by Nick Tune
- https://medium.com/nick-tune-tech-strategy-blog/architecture-ownership-patterns-for-team-topologies-part-2-single-team-patterns-943d31854285

Цикл статей о том, как выравнивать команды и компоненты системы. Полезна всем, кто распределяет зоны ответственностей команд.

#DDD #Microservices #SoftwareArchitecture

Прошу меня извинить за столь длительную паузу в рассмотрении темы Monolith First vs. Microservices First. После праздников накопилось много дел.

По этой теме я хотел бы добавить еще одно высказывание от разработчиков популярного микросервисного фреймворка go-kit:

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

Why microservices? Almost all of contemporary software engineering is focused on the singular goal of improving time-to-market. Microservices are an evolution of the service-oriented architecture pattern that elegantly eliminate organizational friction, giving your engineers and teams the autonomy they need to continuously ship, iterate, and improve."
- Go kit. A toolkit for microservices.
https://gokit.io/

#DDD #Microservices #SoftwareArchitecture

Таким образом, с одной стороны, Monolith First получается дешевле, так как удешевляет эволюционирование Доменной Модели и изменение концептуальных контуров.

С другой стороны, Microservices First (не прямо, а косвенно, посредством концепции Bounded Contexts) позволяет достигнуть такого уровня автономности команд, который позволяет задействовать сразу большое количество разработчиков. Получается дорого, но быстро.

Каждое решение - это баланс выгод и затрат. Быстрота тоже выражается деньгами. Если оверхед от микросервисов перекрывается выгодой от более раннего выхода на рынок - TTM (time-to-market), то Microservices First может оказаться экономически целесообразней.

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

На другой чаше весов у нас ущерб упущенной выгоды от более позднего выхода продукта на рынок.

Решение является балансом. Для этого рассматривается график экономии от Monolith First и график ущерба упущенной выгоды от роста TTM.

Там где эти графики пересекаются - возникает точка баланса. Вопрос лежит исключительно в бизнес-плоскости.

Если ущерб упущенной выгоды перевешивает, то применяется Microservices First, иначе - Monolith First.

Зачастую, Monolith First оказывается выгоднее. Но экономическая целесообразность Monolith First может оказаться ниже ущерба упущенной выгоды от роста TTM, и тогда баланс решения качнется в сторону Microservices First. Этот баланс зависит от условий каждого конкретного проекта в отдельности. Серебрянной пули нет.

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

📝 "In theory, you don’t need microservices for this if you simply have the discipline to follow clear rules and establish clear boundaries within your monolithic application; in practice, I’ve found this to be the case only very rarely.)"
- "Don’t start with a monolith" by Stefan Tilkov
https://martinfowler.com/articles/dont-start-monolith.html

Сетевые границы решают проблему, известную как creeping coupling или abstraction leak. А это позволяет снизить квалификационные требования к разработчикам, тем более, что Microservices First обычно имеет экономическую целесообразность только при задействовании большого количества разработчиков.

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

All communication between the services themselves are via network calls, to enforce separation between the services and avoid the perils of tight coupling."
- "Building Microservices. Designing Fine-Grained Systems" by Sam Newman

#DDD #Microservices #SoftwareArchitecture

"State Watch. Notify clients when specific values change on the server"
https://martinfowler.com/articles/patterns-of-distributed-systems/state-watch.html

#SoftwareArchitecture #DistributedSystems

Для тех, кто работает с Golang, - смотрел как-то я эту книгу: "Hands-On Software Architecture with Golang. Design and architect highly scalable and robust applications using Go." by Jyotiswarup Raiturkar
Copyright © 2018 Packt Publishing

Она прекрасна. Удивительное сочетание полноты информации и её краткости. Это скорее конспект, а не книга. Курс молодого бойца. Никакой воды - только все самое нужное. Вряд-ли есть другой способ получить такой колоссальный объем знаний из одной книги. Она, поистине, шедевральна в этом смысле.

Дано практически все, что нужно знать разработчику, на примере Golang. Виды согласованностей, в т.ч. Causal Consistency, Векторные Часы, CAP-теорема, способы достижения консенсуса, в т.ч. RAFT, Paxos, 2PC, основы ООП, композиция vs наследование (кстати, на примере зверушек - известный пример), Design Patterns, основы работы с БД, индексы, формы нормализации, виды транзакций (ACID, BACE), матрица уровней изоляции транзакций, брокеры сообщений, принципы масштабирования и многое другое.

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

Раз уж речь зашла про Packt Publishing, то еще было бы уместно упомянуть "Learning Functional Programming in Go. Change the way you approach your applications using functional programming in Go." by Lex Sheehan
Copyright © 2017 Packt Publishing

И "Hands-On High Performance with Go. Boost and optimize the performance of your Golang applications at scale with resilience" by Bob Strecansky
Copyright © 2020 Packt Publishing

#Golang #SoftwareDesing #SoftwareArchitecture #FunctionalProgramming

Обзор книги "Fundamentals of Software Architecture: An Engineering Approach" 1st edition by Mark Richards, Neal Ford
https://apolomodov.medium.com/%D0%BE%D0%B1%D0%B7%D0%BE%D1%80-fundamentals-of-software-architecture-1754c0e78d48

От Alexander Polomodov - Director of digital ecosystem development department at Tinkoff.

#SoftwareArchitecture #Career

Цикл статей Gregor Hohpe о презентационных навыках. На прошлой неделе вышла пятая статья цикла.

- Making Complex Topics Stick (Part 1: Content). Ethos, Logos, and Pathos have to be built-in, not tacked on.
https://architectelevator.com/strategy/complex-topics-stick/

- Making Complex Topics Stick (Part 2: Composition). A list of ingredients doesn’t make a recipe. You need to know the right dosage.
https://architectelevator.com/strategy/logos-ethos-pathos/

- Making Complex Topics Stick (Part 3: Delivery). How to overcome the first curse of speaking: linearity.
https://architectelevator.com/strategy/presenting-like-architect/

- Making Complex Topics Stick (Part 4: Multiplexing). Weaving multiple threads into a single presentation.
https://architectelevator.com/strategy/presenting-multiplex/

- Making Complex Topics Stick (Part 5: Waveforms). Weaving two threads into a single presentation.
https://architectelevator.com/strategy/presenting-waveform/

P.S.: Если кто еще не знает, то по презентационным паттернам есть книга:
- "Presentation patterns: techniques for crafting better presentations" by Neal Ford, Matthew McCullough, Nathaniel Schutta

#SoftwareArchitecture #Career #SoftSkills #Management