Вот такой есть интересный документ в documentation review:
- https://www.plainlanguage.gov/guidelines/
Thanks to @pantafive
#SoftwareArchitecture
- https://www.plainlanguage.gov/guidelines/
Thanks to @pantafive
#SoftwareArchitecture
Digital.gov
Plain Language Guide Series
A series of guides to help you understand and practice writing, designing, and testing plain language
👍2😁1
В период пандемии многие сталкивались с проблемами качества связи видеоконференций. Зачастую причина устраняется проще, чем кажется, и она вовсе не зависит от качества услуг провайдера. Превосходное руководство простым языком от Keenetic: "Способы увеличения скорости соединения, пропускной способности и стабильности беспроводной сети Wi-Fi".
Keenetic
Способы увеличения скорости соединения, пропускной способности и стабильности беспроводной сети Wi-Fi
Всё большую популярность и распространение набирает технология беспроводных сетей Wi-Fi. Многие современные устройства, которые мы используем (смартфон, планшет, ноутбук, роутер, телевизор), умеют ...
👍9🔥1
Forwarded from DDDevotion
Рассказывал сегодня про парное программирование на внутреннем митапе, в процессе поиска инфы наткнулся на исчерпывающее описание практики, которое сделал Сергей Баранов. Рекомендую почитать, независимо от того практикуете или только собираетесь)
Agile Mindset
Парное программирование - Agile Mindset
Парное программирование – одна из самых недопонятых практик экстремального программирования. А раз так – будем разбираться.
👍5
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
А вот и "Version Vector" подоспел в "Patterns of Distributed Systems": - https://martinfowler.com/articles/patterns-of-distributed-systems/version-vector.html Судя по комментарию в правой колонке статьи, отдельной статьи по Version Clock не будет. Version…
Что-то я упустил новые статьи в "Patterns of Distributed Systems":
Paxos:
- https://martinfowler.com/articles/patterns-of-distributed-systems/paxos.html
Two Phase Commit:
- https://martinfowler.com/articles/patterns-of-distributed-systems/two-phase-commit.html
И новые статьи в "Patterns of Legacy Displacement":
Legacy Mimic:
- https://martinfowler.com/articles/patterns-legacy-displacement/legacy-mimic.html
Critical Aggregator:
- https://martinfowler.com/articles/patterns-legacy-displacement/critical-aggregator.html
Replicated Log:
- https://martinfowler.com/articles/patterns-of-distributed-systems/replicated-log.html
Divert the Flow:
- https://martinfowler.com/articles/patterns-legacy-displacement/divert-the-flow.html
#DistributedSystems #SoftwareArchitecture
Paxos:
- https://martinfowler.com/articles/patterns-of-distributed-systems/paxos.html
Two Phase Commit:
- https://martinfowler.com/articles/patterns-of-distributed-systems/two-phase-commit.html
И новые статьи в "Patterns of Legacy Displacement":
Legacy Mimic:
- https://martinfowler.com/articles/patterns-legacy-displacement/legacy-mimic.html
Critical Aggregator:
- https://martinfowler.com/articles/patterns-legacy-displacement/critical-aggregator.html
Replicated Log:
- https://martinfowler.com/articles/patterns-of-distributed-systems/replicated-log.html
Divert the Flow:
- https://martinfowler.com/articles/patterns-legacy-displacement/divert-the-flow.html
#DistributedSystems #SoftwareArchitecture
martinfowler.com
Paxos
Use two consensus building phases to reach safe consensus even
when nodes disconnect
when nodes disconnect
👍5
Python notebook for analysing the Gap of Change modelled in ArchiMate:
- https://github.com/RichDijk/EAGOC
- https://www.researchgate.net/publication/332448224_Analytic_Pattern_and_Tool_for_Analysis_of_a_Gap_of_Changes_in_Enterprise_Architectures
ArchiMate® 3.1 Specification
13. Implementation and Migration Elements
- https://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc10045444
Ну и напомню, на всякий случай, что есть отличное руководство по Agile Architecture.
C4-Model & Event Storming with ArchiMate, см. "Figure 13: Event Storming Model" of "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
Модель by Jean-Baptiste Sarrodie (создатель Archimatetool) здесь:
- https://community.opengroup.org/archimate-user-community/home/-/issues/8
По C4 Model with Archimate есть отдельная статья:
- https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/
#SoftwareArchitecture #Archimate
- https://github.com/RichDijk/EAGOC
- https://www.researchgate.net/publication/332448224_Analytic_Pattern_and_Tool_for_Analysis_of_a_Gap_of_Changes_in_Enterprise_Architectures
ArchiMate® 3.1 Specification
13. Implementation and Migration Elements
- https://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc10045444
Ну и напомню, на всякий случай, что есть отличное руководство по Agile Architecture.
C4-Model & Event Storming with ArchiMate, см. "Figure 13: Event Storming Model" of "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
Модель by Jean-Baptiste Sarrodie (создатель Archimatetool) здесь:
- https://community.opengroup.org/archimate-user-community/home/-/issues/8
По C4 Model with Archimate есть отдельная статья:
- https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/
#SoftwareArchitecture #Archimate
GitHub
GitHub - RichDijk/EAGOC: Python notebook for analysing the Gap of Change modelled in ArchiMate
Python notebook for analysing the Gap of Change modelled in ArchiMate - RichDijk/EAGOC
👍2
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных (Denis Beskov)
Переложили программу самоподготовки на отдельную публичную веб-страницу https://systems.education/junior-analyst-self-study
Добавляйте в закладки)
Добавляйте в закладки)
🔥5👍4
В заметке "Как осуществлять изменения в коллективе" я говорил о том, что:
> "Важно уметь не внедрить изменения, а инициировать и подпитывать их. Больше слушать, спрашивать, меньше говорить."
Mike Cohn в своей вчерашней статье "My Favorite Hard Questions to Ask When Making a Decision" разделяет эту тактику, и даже конкретизирует список вопросов, которые нужно задавать для осуществления влияния.
#Management #SoftSkills
> "Важно уметь не внедрить изменения, а инициировать и подпитывать их. Больше слушать, спрашивать, меньше говорить."
Mike Cohn в своей вчерашней статье "My Favorite Hard Questions to Ask When Making a Decision" разделяет эту тактику, и даже конкретизирует список вопросов, которые нужно задавать для осуществления влияния.
#Management #SoftSkills
Mountain Goat Software
Helpful Questions to Nudge Teams Toward Good Decisions
Use my list of questions to inspire (rather than command) your teams to think clearly and decide intelligently.
👍6🔥5🤩1
Forwarded from DDDevotion
Андрей Ганичев @Ami_G0 запостил перевод статьи Камиля Гржибека про модульный монолит https://habr.com/en/company/dododev/blog/650721/
Читайте, комментируйте, нажимайте стрелочку вверх ⬆️
Читайте, комментируйте, нажимайте стрелочку вверх ⬆️
Habr
Модульный монолит. Начало
Слово переводчика Привет, меня зовут Андрей и я разработчик. Наша команда работает над мобильным приложением для стартапа Dodo Brands — сети кофеен Дринкит. Несмотря на популярность микросервисов, при...
👍7🔥1🤩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
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
GitHub
GitHub - TeamTopologies/Independent-Service-Heuristics: The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for…
The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. - ...
👍8🔥1🤩1
Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids) by Dimitri Fontaine
- https://github.com/dimitri/pgcopydb
#PostgreSQL
- https://github.com/dimitri/pgcopydb
#PostgreSQL
GitHub
GitHub - dimitri/pgcopydb: Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids)
Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids) - dimitri/pgcopydb
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
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
GitLab
Red Hat Demo Central / Portfolio Architecture - Examples · GitLab
Example diagrams, pieces of diagrams, and examples for importing with URL feature of tooling.
👍8😁1
Forwarded from Блог Сергея Баранова
Закон Конвея. Перевод статьи «How Do Committees Invent?»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
👍5
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Test-first vs test-last approaches" by Vladimir Khorikov https://khorikov.org/posts/2022-01-24-test-first-vs-test-last-approaches/ P.S.: Обсуждали недавно эту тему в чате канала. #TDD #SoftwareDesign
Володя осветил один из частых вопросов:
"Collections and Primitive Obsession" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/collections-primitive-obsession/
#DDD #SoftwareDesign
"Collections and Primitive Obsession" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/collections-primitive-obsession/
#DDD #SoftwareDesign
Enterprise Craftsmanship
Collections and Primitive Obsession
Does the primitive obsession anti-pattern apply to collections? In other words, should you introduce a custom class for a collection?
👍6👎1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Два новых перевода от хабраюзера ArkadiyXIII на статьи Vladik Khononov (@vladik_kh): "Преодоление сложности в CQRS" - https://habr.com/ru/post/588803/ "Распутывание микросервисов или балансировка сложности в распределенных системах" - https://habr.com/ru/post/590165/…
Новый перевод от ArkadiyXIII:
- "Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов"
#DDD #SoftwareArchitecture #SoftwareDesign #Microservices
- "Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов"
#DDD #SoftwareArchitecture #SoftwareDesign #Microservices
Хабр
Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов
Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts». Далее не будут переводится следующие фразы: Notifications...
🔥6👍3👎2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Сравнение брокеров сообщений - https://docs.nats.io/compare-nats #DistributedSystems #SoftwareArchitecture #Microservices #DDD
"Error Handling Patterns for Apache Kafka Applications" by Gerardo Villeda
- https://www.confluent.io/blog/error-handling-patterns-in-kafka/
Неплохая статья, которая затрагивает в т.ч. и проблему очередности доставки сообщений.
#DistributedSystems #SoftwareArchitecture #Microservices #DDD
- https://www.confluent.io/blog/error-handling-patterns-in-kafka/
Неплохая статья, которая затрагивает в т.ч. и проблему очередности доставки сообщений.
#DistributedSystems #SoftwareArchitecture #Microservices #DDD
Confluent
Error Handling Patterns in Kafka
From dead letter queues to related events processed out of order, here are 5 common issues in event streaming applications, and how to fix them with sequential retries.
👍7🔥2👎1
"Software Design: Tidy First?" - новая книга, над которой работает Kent Beck. Читать главы можно уже сейчас:
- https://tidyfirst.substack.com/archive?sort=new
#SoftwareDesign
- https://tidyfirst.substack.com/archive?sort=new
#SoftwareDesign
Substack
Archive - Software Design: Tidy First?
Full archive of all the posts from Software Design: Tidy First?.
👍7🔥2👎1
Forwarded from Архитектура ИТ-решений
Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.
Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
publications.opengroup.org
TOGAF® Series Guide: Microservices Architecture (MSA)
This document is part of the TOGAF Standard, 10th Edition.
This document provides guidance on how the architect can use the TOGAF® Standard to develop, manage, and govern Microservices Architecture (MSA) or any architecture where MSA is part of the scope.
This document provides guidance on how the architect can use the TOGAF® Standard to develop, manage, and govern Microservices Architecture (MSA) or any architecture where MSA is part of the scope.
👍1