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
В заметке "Как осуществлять изменения в коллективе" я говорил о том, что:

> "Важно уметь не внедрить изменения, а инициировать и подпитывать их. Больше слушать, спрашивать, меньше говорить."

Mike Cohn в своей вчерашней статье "My Favorite Hard Questions to Ask When Making a Decision" разделяет эту тактику, и даже конкретизирует список вопросов, которые нужно задавать для осуществления влияния.

#Management #SoftSkills
👍6🔥5🤩1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Forget monoliths vs. microservices. Cognitive load is what matters." от авторов книги "Team Topologies" - https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters Thanks to @romanvt #Microservices #TeamTopologies…
📝 "For some companies, the abstract terminology of Domain-Driven Design is a barrier to adoption.

Independent Service Heuristics from
@TeamTopologies is a good alternative which helps a diverse group to collaboratively explore stream and domain boundaries.

https://github.com/TeamTopologies/Independent-Service-Heuristics

It's also a great tool for getting people to see the value of DDD techniques like Event Storming 😀"


-- Nick Tune

https://twitter.com/ntcoding/status/1492487513591721990?t=5T2EyF2fXcHPU7JR3aieng&s=19

P.S.: архитектура все больше и больше становится неотделимой от управления.

#DDD #TeamTopologies #SoftwareArchitecture #SoftwareDesign
👍8🔥1🤩1
Red Hat Portfolio Architecture Examples

This repository provides examples of customer implementations using Red Hat product portfolio. These architectural blueprints can be used as is or adapted to meet the customer requirements. The architectural diagrams are created using the open source tool draw.io.

https://gitlab.com/redhatdemocentral/portfolio-architecture-examples

Thanks to @pantafive

#SoftwareArchitecture
👍8😁1
Закон Конвея. Перевод статьи «How Do Committees Invent?»

Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.

http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/

Несколько цитат:

👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»

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

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

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

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

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

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

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

«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
👍5
"Software Design: Tidy First?" - новая книга, над которой работает Kent Beck. Читать главы можно уже сейчас:
- https://tidyfirst.substack.com/archive?sort=new

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

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

https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158

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

Почему это важно?

В последние годы один из популярных подходов для проектирования продуктовой структуры под решение на микросервисах — Team Topologies, в основе которого как раз лежит гипотеза Данбара о том, что мы можем поддерживать не более пяти глубоких (интимных) дружеских отношений, примерно 150 приятельских контактов, но можем знать имена до 1500 человек.

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

В общем, эти выводы ставят под сомнение опирающиеся на число Данбара структуры в Team Topologies и Agile Release Train в Scaled Agile. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.
👍19
Когда спрашивают зачем нужен слой абстракции от БД:
😁11👍3
Forwarded from SecurityLab.ru
ФСТЭК отзовет более 50 продуктов иностранных разработчиков, которые приостановили свою деятельность в России

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

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

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

https://www.securitylab.ru/news/530814.php?r=1
😁13👍3🎉2🤔1🤯1