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.47K 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
#materials #GDPR

Обновлённая настольная книга по GDPR от Алексея Мунтяна, только на RPPA.ru.

💡Использование: твой путеводитель в мире гдпр.
Forwarded from DDDevotion
Рассказывал сегодня про парное программирование на внутреннем митапе, в процессе поиска инфы наткнулся на исчерпывающее описание практики, которое сделал Сергей Баранов. Рекомендую почитать, независимо от того практикуете или только собираетесь)
👍5
В заметке "Как осуществлять изменения в коллективе" я говорил о том, что:

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

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