"if someone thinks refactoring belongs on the backlog, they probably don't understand refactoring, or backlogs, or both."
- Ron Jeffries
https://twitter.com/RonJeffries/status/1453102208887709700?t=fGEcCfNDt3hQSdVn6f7Ijg&s=19
Значение термина refactoring, действительно, зачастую понимают не все. И, возможно, именно поэтому, в треде появился термин rearchitect.
Еще Ward Cunningham говорил:
"Refactoring is not rewriting, although many people think they are the same."
"Refactoring is a kind of reorganization. Technically, it comes from mathematics when you factor an expression into an equivalence - the factors are cleaner ways of expressing the same statement."
- https://news.1rj.ru/str/emacsway_log/205
- https://news.1rj.ru/str/emacsway_log/206
- https://news.1rj.ru/str/emacsway_log/207
Refactoring - это способ управления сложностью, путем декомпозиции сложности до уровня, когда отдельно взятый её фрагмент сможет быть рассмотрен изолированно в пределах краткосрочной памяти человека.
Интересно, что Grady Booch возлагал обязанность по управлению сложностью на архитектуру, говоря, что архитектура - это многоуровневая система абстракций. Где назначение абстракций - управление сложностью. С той лишь разницей, что в refactiring мы должны соблюдать условие "equivalence":
"Refactoring implies equivalence; the beginning and end products must be functionally identical."
Иными словами, refactoring не должен изменять поведения системы:
"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."
- Martin Fowler in "Refactoring: Improving the Design of Existing Code"
Ну а о том, что такое Backlog, в этом канале уже было:
- https://news.1rj.ru/str/emacsway_log/499
PBI - это требование в условиях недостаточной полноты требований. Причем, требование может изменяться в процессе снижения неопределенности, а значит, как оно тогда может что-то "требовать"? Т.е. это требование-гипотеза, но его суть от этого не меняется - в текущем моменте это - требование.
Единственное требование, которое может быть достигнуто в результате refactoring - это Modifiability. Но и тут засада, ибо NFR должны достигаться совместно с FR.
- https://news.1rj.ru/str/emacsway_log/463
- https://news.1rj.ru/str/emacsway_log/464
К тому же в популярных Agile-моделях Quality уже давно стало константой:
- https://news.1rj.ru/str/emacsway_log/428
Можно ли завести Spike на refactoring? По сути - нет, так как refactoring не разделяет со Spike цели разрешения неопределенности. Хотя, поскольку в результате refactoring повышается точность оценки, то он может выполняться и в процессе Spike.
Интересно, что еще в книге "Planning Extreme Programming" Kent Beck цитировал автора твита:
"Ron Jeffries claims he can turn any technical task into a business-oriented story the customer can either schedule this iteration or not as she chooses. There's something to be said for not having any technical tasks. Once you start down the slippery slope of setting the priority for technical reasons, it's hard to stop."
#SoftwareDesign #Agile #Refactoring
- Ron Jeffries
https://twitter.com/RonJeffries/status/1453102208887709700?t=fGEcCfNDt3hQSdVn6f7Ijg&s=19
Значение термина refactoring, действительно, зачастую понимают не все. И, возможно, именно поэтому, в треде появился термин rearchitect.
Еще Ward Cunningham говорил:
"Refactoring is not rewriting, although many people think they are the same."
"Refactoring is a kind of reorganization. Technically, it comes from mathematics when you factor an expression into an equivalence - the factors are cleaner ways of expressing the same statement."
- https://news.1rj.ru/str/emacsway_log/205
- https://news.1rj.ru/str/emacsway_log/206
- https://news.1rj.ru/str/emacsway_log/207
Refactoring - это способ управления сложностью, путем декомпозиции сложности до уровня, когда отдельно взятый её фрагмент сможет быть рассмотрен изолированно в пределах краткосрочной памяти человека.
Интересно, что Grady Booch возлагал обязанность по управлению сложностью на архитектуру, говоря, что архитектура - это многоуровневая система абстракций. Где назначение абстракций - управление сложностью. С той лишь разницей, что в refactiring мы должны соблюдать условие "equivalence":
"Refactoring implies equivalence; the beginning and end products must be functionally identical."
Иными словами, refactoring не должен изменять поведения системы:
"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."
- Martin Fowler in "Refactoring: Improving the Design of Existing Code"
Ну а о том, что такое Backlog, в этом канале уже было:
- https://news.1rj.ru/str/emacsway_log/499
PBI - это требование в условиях недостаточной полноты требований. Причем, требование может изменяться в процессе снижения неопределенности, а значит, как оно тогда может что-то "требовать"? Т.е. это требование-гипотеза, но его суть от этого не меняется - в текущем моменте это - требование.
Единственное требование, которое может быть достигнуто в результате refactoring - это Modifiability. Но и тут засада, ибо NFR должны достигаться совместно с FR.
- https://news.1rj.ru/str/emacsway_log/463
- https://news.1rj.ru/str/emacsway_log/464
К тому же в популярных Agile-моделях Quality уже давно стало константой:
- https://news.1rj.ru/str/emacsway_log/428
Можно ли завести Spike на refactoring? По сути - нет, так как refactoring не разделяет со Spike цели разрешения неопределенности. Хотя, поскольку в результате refactoring повышается точность оценки, то он может выполняться и в процессе Spike.
Интересно, что еще в книге "Planning Extreme Programming" Kent Beck цитировал автора твита:
"Ron Jeffries claims he can turn any technical task into a business-oriented story the customer can either schedule this iteration or not as she chooses. There's something to be said for not having any technical tasks. Once you start down the slippery slope of setting the priority for technical reasons, it's hard to stop."
#SoftwareDesign #Agile #Refactoring
Twitter
Ron Jeffries
if someone thinks refactoring belongs on the backlog, they probably don't understand refactoring, or backlogs, or both.
Довольно неплохая библиотека от Nginx со свободным доступом:
https://www.nginx.com/resources/library/
#Microservices #SoftwareArchitecture #DistributedSystems
https://www.nginx.com/resources/library/
#Microservices #SoftwareArchitecture #DistributedSystems
F5, Inc.
Welcome to F5 NGINX
NIGINX is part of F5, and all previous NGINX.com links now redirect to content on F5.com. Don't worry, we still have all your needs covered to navigate to the pages you're looking for.
Forwarded from DDDevotion
Хабраюзер ArkadiyXIII продолжает серию переводов важных статей про DDD и около. На этот раз выбор пал на статью Влада https://habr.com/en/post/587520/
Habr
Преодоление сложности в самом сердце DDD
Эта статья является переводом материала «Tackling Complexity in the Heart of DDD». Давайте проведем небольшой эксперимент: попробуем объяснить суть предметно-ориентированного проектирования (DDD)...
Я частенько замечаю, как вопросы в телеграме зачастую остаются недостаточно раскрытыми, потому что раскрывать их в письменной форме неудобно. Нужно визуализировать, рисовать диаграммы, наблюдать за обратной связью, чтобы убедиться в том, что собеседник правильно понял.
Есть желание внести немного реальной оффлайн-жизни в сообщество. Можно встречаться на регулярной основе (ежемесячно) в полуформальной обстановке, обмениваться опытом, устраивать панельные дискуссии и доклады по вопросам DDD, системной архитектуры, качества кода и процессов разработки. А после официальной части можно еще и продолжить общение в неформальной обстановке в каком-нибудь уютном заведении Москвы.
Изначально я думал только о неформальных встречах в каком-нибудь кафе, но, на всякий случай, поинтересовался у себя в офисе о возможности занимать большую переговорную.
В офисе пошли навстречу, и даже предложили несколько вариантов размещения, в зависимости от численности.
Об офисе я уже говорил. Если кто-то пропустил, то коротко повторюсь:
🔹 https://stroi.mos.ru/news/proiekt-bts-akadiemik-poluchil-miezhdunarodnuiu-arkhitiekturnuiu-priemiiu
🔹 https://archi.ru/projects/russia/10721/biznes-centr-akademik
🔹 https://bc-academic.ru/
Основной формат встреч предполагает свободное общение, панельные дискуссии, тематические доклады и разбор вопросов от участников сообщества. Причем, прорабатывать вопросы до конца. Если вопрос нельзя решить во время встречи, то он переносится на следующую встречу, чтоб участники могли подготовиться по теории.
На данный момент, чтоб определиться с вариантом размещения встреч, мне нужна информация о том, кто и какое участие может принять в жизни сообщества. Для этого, прошу персонифицировано проголосовать по ссылке:
🔹 https://news.1rj.ru/str/emacsway_chat/2183
Есть желание внести немного реальной оффлайн-жизни в сообщество. Можно встречаться на регулярной основе (ежемесячно) в полуформальной обстановке, обмениваться опытом, устраивать панельные дискуссии и доклады по вопросам DDD, системной архитектуры, качества кода и процессов разработки. А после официальной части можно еще и продолжить общение в неформальной обстановке в каком-нибудь уютном заведении Москвы.
Изначально я думал только о неформальных встречах в каком-нибудь кафе, но, на всякий случай, поинтересовался у себя в офисе о возможности занимать большую переговорную.
В офисе пошли навстречу, и даже предложили несколько вариантов размещения, в зависимости от численности.
Об офисе я уже говорил. Если кто-то пропустил, то коротко повторюсь:
🔹 https://stroi.mos.ru/news/proiekt-bts-akadiemik-poluchil-miezhdunarodnuiu-arkhitiekturnuiu-priemiiu
🔹 https://archi.ru/projects/russia/10721/biznes-centr-akademik
🔹 https://bc-academic.ru/
Основной формат встреч предполагает свободное общение, панельные дискуссии, тематические доклады и разбор вопросов от участников сообщества. Причем, прорабатывать вопросы до конца. Если вопрос нельзя решить во время встречи, то он переносится на следующую встречу, чтоб участники могли подготовиться по теории.
На данный момент, чтоб определиться с вариантом размещения встреч, мне нужна информация о том, кто и какое участие может принять в жизни сообщества. Для этого, прошу персонифицировано проголосовать по ссылке:
🔹 https://news.1rj.ru/str/emacsway_chat/2183
Telegram
Ivan in DDDevotion chat
> Мне проще это иллюстрировать UML диаграммой вариантов использлвания
Ничто не мешает запланировать встречу в Zoom, MS Teams, etc. Если Вы в Москве, то можно договориться об оффлайн-встречах сообщества где-нибудь в кафе Москва-Сити, например.
Я могу у себя…
Ничто не мешает запланировать встречу в Zoom, MS Teams, etc. Если Вы в Москве, то можно договориться об оффлайн-встречах сообщества где-нибудь в кафе Москва-Сити, например.
Я могу у себя…
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Сервис для коллективной разработки Event Storming и Context Mapping от Vaughn Vernon: Domain Modeling, Robot! - https://domorobo.to/ - https://twitter.com/VaughnVernon/status/1443670501235167244?s=20 #DDD #EventStorming #SoftwareArchitecture
Сервис от Vaughn Vernon для коллективного моделирования с поддержкой Event Storming, Context Mapping и Topographic Architecture Modeling, domorobo.to обзавелся новой документацией:
https://twitter.com/VaughnVernon/status/1458335394609582082?t=TfC0aPOI5PurTj_l6xa_zQ&s=19
#DDD #EventStorming #SoftwareArchitecture
https://twitter.com/VaughnVernon/status/1458335394609582082?t=TfC0aPOI5PurTj_l6xa_zQ&s=19
#DDD #EventStorming #SoftwareArchitecture
Twitter
Vaughn Vernon
Our @vlingo_io #DomoRoboto team has new documentation and released new features and tweaks for easier modeling. domorobo.to See [How To DomoRoboto] on the home page. Check out the merge of #DDDesign Context Mapping and our #TopoArchitecture modeling in one…
Алексей Зимарев ( @zimareff ) делает Sample application using Eventuous .NET:
- https://github.com/Eventuous/dotnet-sample
#DDD #EventStorming #CQRS #SoftwareArchitecture
- https://github.com/Eventuous/dotnet-sample
#DDD #EventStorming #CQRS #SoftwareArchitecture
GitHub
GitHub - Eventuous/dotnet-sample: Sample application using Eventuous .NET
Sample application using Eventuous .NET. Contribute to Eventuous/dotnet-sample development by creating an account on GitHub.
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Ребята из Three Dots Labs, разработчики DDD-framework Watermill на Golang, создали сообщество в Discord: - https://discord.com/invite/kTVsGjPYDn #Microservices #DDD #SoftwareDesign #SoftwareArchitecture #Golang
go-web-app-antipatterns - Short examples of common anti-patterns in Go Web Applications.
- https://github.com/ThreeDotsLabs/go-web-app-antipatterns
Ребята из Three Dots Labs, разработчики DDD-framework Watermill на Golang, начали собирать каталог антипаттернов.
#DDD #SoftwareDesign #SoftwareArchitecture #Golang
- https://github.com/ThreeDotsLabs/go-web-app-antipatterns
Ребята из Three Dots Labs, разработчики DDD-framework Watermill на Golang, начали собирать каталог антипаттернов.
#DDD #SoftwareDesign #SoftwareArchitecture #Golang
GitHub
GitHub - ThreeDotsLabs/go-web-app-antipatterns: Short examples of common anti-patterns in Go Web Applications.
Short examples of common anti-patterns in Go Web Applications. - ThreeDotsLabs/go-web-app-antipatterns
👍1
Интересный курс по основам коммуникации: https://www.youtube.com/watch?v=mS8EKBfLS9Q&list=PL72i_EMUg8BPfZgYbUH7ack9JqNkXaNiB
Неплохое соотношение легкости изложения и информационной ценности. Без воды.
Там есть и другие, актуальные для архитектора, видео на тему коммуникативной, управленческой и социальной психологии:
- https://youtube.com/channel/UCSN7G8syJUaRiXrw1l0qk_g
#SoftSkills #Career #Management
Неплохое соотношение легкости изложения и информационной ценности. Без воды.
Там есть и другие, актуальные для архитектора, видео на тему коммуникативной, управленческой и социальной психологии:
- https://youtube.com/channel/UCSN7G8syJUaRiXrw1l0qk_g
#SoftSkills #Career #Management
YouTube
Коммуникация в три этапа - Курс SoftSkills Pro
Успешные коммуникаторы держат в голове три основных принципа, которые помогают не сбиваться с намеченного пути.
В этом уроке мы разберём эти принципы.
SoftSkills Pro - Онлайн-школа личной эффективности.
Инстаграм: https://www.instagram.com/softskills.pro/…
В этом уроке мы разберём эти принципы.
SoftSkills Pro - Онлайн-школа личной эффективности.
Инстаграм: https://www.instagram.com/softskills.pro/…
Forwarded from Обсуждаем публикации канала "Архитектура ИТ-решений"
Я однажды вот этот курс нашел. На мой взгляд, идеальное по соотношению простота/польза введение в коммуникации
YouTube
Коммуникация в три этапа - Курс SoftSkills Pro
Успешные коммуникаторы держат в голове три основных принципа, которые помогают не сбиваться с намеченного пути.
В этом уроке мы разберём эти принципы.
SoftSkills Pro - Онлайн-школа личной эффективности.
Инстаграм: https://www.instagram.com/softskills.pro/…
В этом уроке мы разберём эти принципы.
SoftSkills Pro - Онлайн-школа личной эффективности.
Инстаграм: https://www.instagram.com/softskills.pro/…
Пролистал книгу от топ-переговорщика ФБР Крисс Водс "Договориться не проблема. Как добиваться своего без конфликтов и ненужных уступок.", и кое-что полезное для себя подчерпнул.
В оригинале называется "Never split the difference: negotiating as if life depended on it" by Chris Voss
#SoftSkills #Career #Management
В оригинале называется "Never split the difference: negotiating as if life depended on it" by Chris Voss
#SoftSkills #Career #Management
Forwarded from InvestFuture
🤝 Как добиваться своего без конфликтов и уступок?
Главным героем книжной рубрики на этой неделе стал американский эксперт по переговорам Крис Восс. Попробуем разобраться, что нужно знать о переговорах в бизнесе и повседневной жизни, а также ответим на следующие вопросы:
Что такое активное слушание?
Как создать у оппонента иллюзию контроля?
Какие бывают стили ведения переговоров?
Обсуждаем и разыгрываем книгу "Договориться не проблема" в очередном выпуске книжной рубрики. Там же — подведение итогов конкурса прошлой недели!
🎬 Смотреть видео!
Главным героем книжной рубрики на этой неделе стал американский эксперт по переговорам Крис Восс. Попробуем разобраться, что нужно знать о переговорах в бизнесе и повседневной жизни, а также ответим на следующие вопросы:
Что такое активное слушание?
Как создать у оппонента иллюзию контроля?
Какие бывают стили ведения переговоров?
Обсуждаем и разыгрываем книгу "Договориться не проблема" в очередном выпуске книжной рубрики. Там же — подведение итогов конкурса прошлой недели!
🎬 Смотреть видео!
Forwarded from Mens Business Club
5️⃣ уроков успеха, которые преподносит нам природа:
1. Первому из уроков достижения успеха можно выучить у маленьких львят. Этот урок успеха называется – “запачкайте морду кровью”.
Они умеют учиться. Они учатся у старших более опытных львов. И учатся они не по учебникам и разговорам, а на деле. Они точно знают – чтобы научиться охотится нужно запачкать морду кровью. Мы же боимся даже руки замарать. Мы садимся за парты и смотрим на стоящего у доски разодетого зайца, который учит нас охотиться. Или еще хуже, закрываемся дома и учимся сами с собой, а когда приходит время охоты, мы не то что охотится не умеем, мы боимся запаха крови.
2. Второй урок успеха можно выучить у рыбы. Он называется “урок потока”.
Рыба всегда плывет против течения и вопреки общему мнению это правильно. Она это делает не для того чтобы усложнить себе жизнь, а для того чтобы больше воды мимо себя пропустить. Так мимо нее в потоке воды проплывает больше еды и кислорода. Так ее жизнь становится в несколько раз богаче. Мы же, в отличие от рыбы, всегда пытаемся плыть по течению в стагнирующем потоке, и в результате вместо 40 лет жизненного опыта, мы нажили однолетний жизненный опыт 40 раз. Мы не хотим выходить из комфортной зоны и потом удивляемся, почему в жизни было так мало возможностей. Мы хотим выиграть лотерею жизни, даже не купив лотерейного билета.
3. Третий урок успеха мы можем научиться у дятла. Да, у дятла! Он называется “урок реалистичной фокусировки”.
Дятел во многом умнее нас. Да, он бьется головой о дерево, но делает это он очень успешно. Он реалистичен – он не пытается разбить дерево пополам одним ударом, как это хотят сделать многие из нас, и он сфокусирован – он не стучит в дерево со всех сторон. Он фокусировано бьет в одну и ту же точку, медленно продвигаясь к своему червячку. Нам же нужен не червяк, а сразу змей, и найти его мы хотим не в плотном дереве, а лишь присыпанным листьями на земле.
4. Четвертый урок успеха мы можем выучить у собаки. Он социальный и называется “повиляй хвостом первый”.
В 21 веке уже не важно, что делаешь ты, а важно на что ты мотивируешь других людей. И прекрасный пример здесь собака. Собака не думает: “Сначала ты меня домой приведи, накорми и помой, а потом я тебе повиляю хвостом.” Собака первая отдает свои чувства и лишь потом получает взамен то, что ей нужно. При этом она не заставляет вас ей ничего отдавать, она делает так, что вы сами хотите это сделать.
5. Пятый урок успеха нам должна преподать змея. Урок называется “не надо ныть”.
Она не думает: “У меня нет ни рук, ни ног, у меня плохое зрение, я родилась не в той стране, меня никто не любит, мои родители обо мне не заботились с момента как я вылупилась”. Змея обходится тем, что у нее есть, и мы даже боимся этого “животного-инвалида”. И если ей что-то не нравится, она просто меняет шкуру и ползет дальше без сожалений.
1. Первому из уроков достижения успеха можно выучить у маленьких львят. Этот урок успеха называется – “запачкайте морду кровью”.
Они умеют учиться. Они учатся у старших более опытных львов. И учатся они не по учебникам и разговорам, а на деле. Они точно знают – чтобы научиться охотится нужно запачкать морду кровью. Мы же боимся даже руки замарать. Мы садимся за парты и смотрим на стоящего у доски разодетого зайца, который учит нас охотиться. Или еще хуже, закрываемся дома и учимся сами с собой, а когда приходит время охоты, мы не то что охотится не умеем, мы боимся запаха крови.
2. Второй урок успеха можно выучить у рыбы. Он называется “урок потока”.
Рыба всегда плывет против течения и вопреки общему мнению это правильно. Она это делает не для того чтобы усложнить себе жизнь, а для того чтобы больше воды мимо себя пропустить. Так мимо нее в потоке воды проплывает больше еды и кислорода. Так ее жизнь становится в несколько раз богаче. Мы же, в отличие от рыбы, всегда пытаемся плыть по течению в стагнирующем потоке, и в результате вместо 40 лет жизненного опыта, мы нажили однолетний жизненный опыт 40 раз. Мы не хотим выходить из комфортной зоны и потом удивляемся, почему в жизни было так мало возможностей. Мы хотим выиграть лотерею жизни, даже не купив лотерейного билета.
3. Третий урок успеха мы можем научиться у дятла. Да, у дятла! Он называется “урок реалистичной фокусировки”.
Дятел во многом умнее нас. Да, он бьется головой о дерево, но делает это он очень успешно. Он реалистичен – он не пытается разбить дерево пополам одним ударом, как это хотят сделать многие из нас, и он сфокусирован – он не стучит в дерево со всех сторон. Он фокусировано бьет в одну и ту же точку, медленно продвигаясь к своему червячку. Нам же нужен не червяк, а сразу змей, и найти его мы хотим не в плотном дереве, а лишь присыпанным листьями на земле.
4. Четвертый урок успеха мы можем выучить у собаки. Он социальный и называется “повиляй хвостом первый”.
В 21 веке уже не важно, что делаешь ты, а важно на что ты мотивируешь других людей. И прекрасный пример здесь собака. Собака не думает: “Сначала ты меня домой приведи, накорми и помой, а потом я тебе повиляю хвостом.” Собака первая отдает свои чувства и лишь потом получает взамен то, что ей нужно. При этом она не заставляет вас ей ничего отдавать, она делает так, что вы сами хотите это сделать.
5. Пятый урок успеха нам должна преподать змея. Урок называется “не надо ныть”.
Она не думает: “У меня нет ни рук, ни ног, у меня плохое зрение, я родилась не в той стране, меня никто не любит, мои родители обо мне не заботились с момента как я вылупилась”. Змея обходится тем, что у нее есть, и мы даже боимся этого “животного-инвалида”. И если ей что-то не нравится, она просто меняет шкуру и ползет дальше без сожалений.
Forwarded from Архитектура ИТ-решений
Курс по микросервисам[2] я сейчас провожу примерно каждые три недели. И каждый раз практические занятия по рисованию архитектур съедают часть и без того коротких 24 академ.часов. Похоже, единственный выход жестко фиксировать нотацию. В следующем потоке устрою эксперимент с нотацией от Мэтта Макларти[1], у которого синхронные взаимодействия обозначаются прямой стрелочкой, асинхронные волнистой, запросы помечаются стрелочкой со значком вопроса (?), команды маркируются символом (!) и т.д. И, безусловно, поделюсь результатами эксперимента
[1] A visual language for digital integration
[2] Курс Микросервисная архитектура
[1] A visual language for digital integration
[2] Курс Микросервисная архитектура
MuleSoft Blog
A visual language for digital integration
In my last blog, I introduced terminology that can be used to label common concepts and patterns in the realm…
Forwarded from Архитектура ИТ-решений
А вот предложения по классификации интеграционных взаимодействий от Билгина Ибряма (Red Hat) https://www.infoq.com/articles/microservices-inside-out/
Очень многие эксперты сейчас пытаются нащупать новый взгляд, новую модель интеграции приложений, да и говорят примерно об одних и тех же вещах. В общем, наблюдаем дальше
Очень многие эксперты сейчас пытаются нащупать новый взгляд, новую модель интеграции приложений, да и говорят примерно об одних и тех же вещах. В общем, наблюдаем дальше
InfoQ
Turning Microservices Inside-Out
Turning microservices inside-out means moving past a single, request/response API to designing microservices with an inbound API for queries and commands, an outbound APIs to emit events, and a meta API to describe them both. A database can be supplemented…
Forwarded from @yarosh_log
Там это … есть CNCF AWS StepFunctions подобная спека
https://serverlessworkflow.io/
и даже пару совместимых проектов, даже с BPMN’ом
https://kogito.kie.org/
https://serverlessworkflow.io/
и даже пару совместимых проектов, даже с BPMN’ом
https://kogito.kie.org/
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Team Topologies Book References - https://github.com/TeamTopologies/Team-Topologies-Book-References #Management #Agile #SoftwareArchitecture #TeamTopologies
"The strong and weak forces of architecture" by Evan Bottcher
- https://martinfowler.com/articles/strong-weak-arch.html
Еще одна статья на тему топологии и масштабирования команд.
#TeamTopologies #Management #SoftwareArchitecture
- https://martinfowler.com/articles/strong-weak-arch.html
Еще одна статья на тему топологии и масштабирования команд.
#TeamTopologies #Management #SoftwareArchitecture
martinfowler.com
The strong and weak forces of architecture
The forces for architectural alignment vary on domain relationships.
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software" by Stefan Hofer, Henning Schwentner Part of the Addison-Wesley Signature Series (Vernon) series. - https://www.informit.com/store/domain-storytelling-a-collaborative…
"Why EventStorming practitioners should try Domain Storytelling" by Henning Schwentner and Stefan Hofer
- https://www.eventstore.com/blog/4-strategies-for-future-events-with-event-sourcing
#DDD #SoftwareDesign #SoftwareArchitecture #EventStorming #DomainStorytelling
- https://www.eventstore.com/blog/4-strategies-for-future-events-with-event-sourcing
#DDD #SoftwareDesign #SoftwareArchitecture #EventStorming #DomainStorytelling
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Minimize Team Cognitive Load to Increase Flow" by Matthew Skelton - https://itrevolution.com/minimize-cognitive-load-of-teams/ Хорошая статья о связи топологии команд с DDD. Комментарий Nick Tune: - https://twitter.com/ntcoding/status/1444232557080494086?s=19…
Часто слышу вопрос "читать ли синюю книгу Эванса, или она уже устарела?" Прекрасный ответ на этот вопрос дает Nick Tune в статье
"domain-driven design (ddd) vs Domain-Driven Design (DDD)"
- https://medium.com/nick-tune-tech-strategy-blog/domain-driven-design-ddd-vs-domain-driven-design-ddd-10ec1d5ca6c7
#DDD #SoftwareArchitecture
"domain-driven design (ddd) vs Domain-Driven Design (DDD)"
- https://medium.com/nick-tune-tech-strategy-blog/domain-driven-design-ddd-vs-domain-driven-design-ddd-10ec1d5ca6c7
#DDD #SoftwareArchitecture
Medium
domain-driven design (ddd) vs Domain-Driven Design (DDD)
Practically everybody is doing domain-driven design in some form. When we build new products and services, we’re identifying unmet needs in…
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Немного о топологии DevOps команд в масштабируемом Agile: "What Team Structure is Right for DevOps to Flourish?" by Matthew Skelton https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/ "DevOps Topologies" https…
Паттерны DevOps топологии:
Compliance in a DevOps Culture. Integrating Compliance Controls and Audit into CI/CD Processes
Integrating the necessary Security Controls and Audit capabilities to satisfy Compliance requirements within a DevOps culture can capitalize on CI/CD pipeline automation, but presents unique challenges as an organization scales. Understanding the second order implications and unintended consequences caused by the chosen implementation is key to building an effective, secure, and scalable solution.
- https://martinfowler.com/articles/devops-compliance.html
#Management #SoftwareArchitecture #Agile #DevOps
Compliance in a DevOps Culture. Integrating Compliance Controls and Audit into CI/CD Processes
Integrating the necessary Security Controls and Audit capabilities to satisfy Compliance requirements within a DevOps culture can capitalize on CI/CD pipeline automation, but presents unique challenges as an organization scales. Understanding the second order implications and unintended consequences caused by the chosen implementation is key to building an effective, secure, and scalable solution.
- https://martinfowler.com/articles/devops-compliance.html
#Management #SoftwareArchitecture #Agile #DevOps
martinfowler.com
Compliance in a DevOps Culture
A DevOps Compliance culture can yield enormous benefits provided the strategy is tailored to the organization.
Forwarded from Andrey Ratushniy
Друзья, буквально неделю назад Владимир Хориков (@vkhorikov ) выступил с докладом в котором он рассказывает про основные принципы и строительные блоки DDD-методологии: контексты, единый язык, модели. Обращает внимание на недостатки тех или иных приемов при разработке ПО. Вобщем, настоятельно рекомендую, особенно тем, кто является новичком в DDD https://www.youtube.com/watch?v=kPV1SkdSnhE
YouTube
Vladimir Khorikov: DDD in a nutshell
Takeaways: the main principles of DDD and why DDD is important in business applications, technical aspects and patterns in DDD, including the difference between anemic and rich domain models, the relation between DDD, microservices and Cloud.
Vladimir Khorikov…
Vladimir Khorikov…
👍1