emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
А поскольку тут собрались главным образом архитекторы, то, дабы не впасть в Культ Карго, возникает вопрос, а какую проблему решает Agile? Вот здесь перечислен список решаемых им проблем: https://news.1rj.ru/str/ru_arc/288 Это список является причиной появления Agile…
Но обратимся к основателям Scrum.
💬 One of the purposes of the plan is to convince someone to fund the project. The plan should provide sufficient details to satisfy a source of funding that the project has merit, that it will deliver certain things at certain times, that the benefits outweigh the costs and risks, and that the people who will staff the project are sufficiently compentent to execute the plan.
-- Agile project management with Scrum by Ken Schwaber.
В основу Scrum положен цикл PDCA, первая буква которого расшифровывается как Plan. Об этом пишет другой основатель Scrum - Jeff Sutherland. Кроме этого, он пишет:
💬 Release Planning & Initial Product Backlog Refinement
A question that is sometimes asked is how, in an iterative model, can long-term release planning be done. There are two cases to consider: (1) a new product in its first release, and (2) an existing product in a later release.
In the case of a new product, or an existing product just adopting Scrum, there is the need to do initial Product Backlog refinement before the first Sprint, where the Product Owner and team shape a proper Scrum Product Backlog. This could take a few days or a week, and involves a vision workshop, some detailed requirements analysis, and estimation of all the items identified for the first release.
Surprisingly in Scrum, in the case of an established product with an established Product Backlog, there should not be the need for any special or extensive release planning for the next release. Why?
Because the Product Owner and team should be doing Product Backlog refinement every Sprint (five or ten percent of each Sprint), continuously preparing for the future. This continuous product development mode obviates the need for the dramatic punctuated prepare-execute-conclude stages one sees in traditional sequential life cycle development.
During an initial Product Backlog refinement workshop and during the continuous backlog refinement each Sprint, the Team and Product Owner will do release planning, refining the estimates, priorities, and content as they learn.
Some releases are date-driven; for example: “We will release
version 2.0 of our project at a trade-show on November 10.” In this situation, the team will complete as many Sprints (and build as many features) as is possible in the time available. Other products require certain features to be built before they can be called complete and the product will not launch until these requirements are satisfied, however long that takes. Since Scrum emphasizes producing potentially shippable code each Sprint, the Product Owner may choose to start doing interim releases, to allow the customer to reap the benefits of completed work sooner.
Since they cannot possibly know everything up front, the focus is on creating and refining a plan to give the release broad direction, and clarify how tradeoff decisions will be made (scope versus schedule, for example). Think of this as the roadmap guiding you towards your final destination; which exact roads you take and the decisions you make during the journey may be determined en route.
Most Product Owners choose one release approach. For example, they will decide a release date, and will work with the team to estimate the Release Backlog items that can be completed by that date. In situations where a “fixed price / fixed date / fixed deliverable” commitment is required – for example, contract development – one or more of those parameters must have a built-in buffer to allow for uncertainty and change; in this respect, Scrum is no different from other approaches. The advantage of Scrum is that new requirements can easily be added into the release at sprint boundaries as long as low prority requirements scheduled later can be removed and still keep the project on time and on budget.
-- "Jeff Sutherland's Scrum Handbook" by Jeff Sutherland
Таким образом, Agile не отрицает и не подменяет собою планирование, а позволяет компенсировать сложность заблаговременно планирования путем адаптации плана.
💬 One of the purposes of the plan is to convince someone to fund the project. The plan should provide sufficient details to satisfy a source of funding that the project has merit, that it will deliver certain things at certain times, that the benefits outweigh the costs and risks, and that the people who will staff the project are sufficiently compentent to execute the plan.
-- Agile project management with Scrum by Ken Schwaber.
В основу Scrum положен цикл PDCA, первая буква которого расшифровывается как Plan. Об этом пишет другой основатель Scrum - Jeff Sutherland. Кроме этого, он пишет:
💬 Release Planning & Initial Product Backlog Refinement
A question that is sometimes asked is how, in an iterative model, can long-term release planning be done. There are two cases to consider: (1) a new product in its first release, and (2) an existing product in a later release.
In the case of a new product, or an existing product just adopting Scrum, there is the need to do initial Product Backlog refinement before the first Sprint, where the Product Owner and team shape a proper Scrum Product Backlog. This could take a few days or a week, and involves a vision workshop, some detailed requirements analysis, and estimation of all the items identified for the first release.
Surprisingly in Scrum, in the case of an established product with an established Product Backlog, there should not be the need for any special or extensive release planning for the next release. Why?
Because the Product Owner and team should be doing Product Backlog refinement every Sprint (five or ten percent of each Sprint), continuously preparing for the future. This continuous product development mode obviates the need for the dramatic punctuated prepare-execute-conclude stages one sees in traditional sequential life cycle development.
During an initial Product Backlog refinement workshop and during the continuous backlog refinement each Sprint, the Team and Product Owner will do release planning, refining the estimates, priorities, and content as they learn.
Some releases are date-driven; for example: “We will release
version 2.0 of our project at a trade-show on November 10.” In this situation, the team will complete as many Sprints (and build as many features) as is possible in the time available. Other products require certain features to be built before they can be called complete and the product will not launch until these requirements are satisfied, however long that takes. Since Scrum emphasizes producing potentially shippable code each Sprint, the Product Owner may choose to start doing interim releases, to allow the customer to reap the benefits of completed work sooner.
Since they cannot possibly know everything up front, the focus is on creating and refining a plan to give the release broad direction, and clarify how tradeoff decisions will be made (scope versus schedule, for example). Think of this as the roadmap guiding you towards your final destination; which exact roads you take and the decisions you make during the journey may be determined en route.
Most Product Owners choose one release approach. For example, they will decide a release date, and will work with the team to estimate the Release Backlog items that can be completed by that date. In situations where a “fixed price / fixed date / fixed deliverable” commitment is required – for example, contract development – one or more of those parameters must have a built-in buffer to allow for uncertainty and change; in this respect, Scrum is no different from other approaches. The advantage of Scrum is that new requirements can easily be added into the release at sprint boundaries as long as low prority requirements scheduled later can be removed and still keep the project on time and on budget.
-- "Jeff Sutherland's Scrum Handbook" by Jeff Sutherland
Таким образом, Agile не отрицает и не подменяет собою планирование, а позволяет компенсировать сложность заблаговременно планирования путем адаптации плана.
👍3❤🔥1🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Это очень важная информация, которая, к сожалению, очень слабо освещена и многим непонятна. Как результат - очень многие не понимают о том, что такое DDD и зачем он вообще нужен. Практически никто не может объяснить своими словами что такое DDD (на самом деле…
Вот эта картинка из главы "1.4.2.2 Relationship between Requirements Models and Design Models" справочника "Handbook of Requirements Modeling According to the IREB Standard", которая слегка модифицирует оригинальную картинку из известной статьи Twin Peak Model , очень хорошо выражает функцию, возложенную на Ubiquitous Language как средства обобщения (и конвергенции) ментальной модели эксперта предметной области и доменной модели решения.
👍5❤2🔥1
Кратко о fitness functions. Любое приложение всегда стремится к энтропии. Как говорил известный в ИТ-индустрии Gregor Hohpe:
💬 It’s almost like enterprise IT is subject to the Second Law of Thermodynamics, which concludes that the entropy in an (isolated) system can never decrease - at best it can be constant, but usually it increases.
-- "Here’s why enterprise IT is so complex" by Gregor Hohpe
Технически невозможно контролировать качество работы каждого разработчика. Это побуждает индустрию искать способы поддержания качества архитектуры на принципиальном уровне. Одним из таких способов является Evolutionary Architecture.
Генетический механизм репродукции реализует адаптивный способ разрешения неопределенности.
Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место неопределенность условий существования. Вдруг завтра прилетит метеорит и изменится состав атмосферы?
В связи с этим, двуполое размножение обеспечивает постоянную генерацию новых генетических комбинаций. Мы просто не знаем какая именно генетическая комбинация окажется наиболее приспособленной к завтрашним условиям окружающей среды.
Те генетические комбинации, которые слабо приспособлены к текущим условиям окружающей среды, не должны препятствовать распространению более приспособленных комбинаций. Иными словами, если существует механизм формирования разнообразия генетических комбинаций, то должен существовать и механизм истребления слабо приспособленных генетических комбинаций. Именно поэтому двуполый механизм репродукции не может выполнять свои функции без хищников, назначение которых сводится к истреблению слабо приспособленных генетических комбинаций. Т.е. к селекции. Это как пропалывание грядки.
Зачастую проблема кодовой базы заключается в том, что никто и ничто не выполняет роль этого самого хищника, истребляющего несоответствующие решения. Поэтому больные решения хорошо размножаются.
Robert Martin говорил, что архитектура - это о том, как не надо делать. Иными словами, архитектурное решение - это сокращение количества возможных вариантов. Т.е. архитектура должна выполнять хищнические функции.
Чем отличаются собаки от волков? Волк имеет естественных врагов-хищников, а собаки - нет.
Вместо хищников, процесс селекции собак выполняют выставки и стандарты пород, которые фиксируют желаемые свойства пород.
Выводок, не соответствующий требованиям стандарта породы и допустимым пределам отклонения, отбраковывается и не получает сертификат соответствия. Его рыночная ценность падает, и он не используется заводчиками для репродукции.
По мере возникновения исторических изменений в породе, в стандарт вносятся изменения, требования ужесточаются, что обеспечивает прогресс породы.
Этот же принцип положен в основу Evolutionary Architecture. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.
Роль стандарта породы выполняют fitness functions (функции соответствия, приспособленности). Они позволяют разработчикам измерить степень соответствия старого варианта системы и нового, и выбрать тот, который соответствует требованиям наилучшим образом.
Понимая, что требования fitness functions будут ужесточаться, разработчик всегда стремится увеличивать запас по требованиям , что вынуждает искать его новые решения и постоянно повышать собственный уровень знаний.
Хотя fitness functions выполняют охранные функции, препятствуя деградации свойств системы, главная их ценность заключается не в этом, а в создании благоприятных условий для постоянного развития уровня квалификации специалистов.
Наиболее важными я считаю fitness functions с нагрузочным и объемным тестированием, которые мгновенно выявляют костыльные запросы и побуждают разработчиков изначально закладывать в систему решения с дальним горизонтом развития, например, такие, как CQRS.
Пример реализации fitness functions.
💬 It’s almost like enterprise IT is subject to the Second Law of Thermodynamics, which concludes that the entropy in an (isolated) system can never decrease - at best it can be constant, but usually it increases.
-- "Here’s why enterprise IT is so complex" by Gregor Hohpe
Технически невозможно контролировать качество работы каждого разработчика. Это побуждает индустрию искать способы поддержания качества архитектуры на принципиальном уровне. Одним из таких способов является Evolutionary Architecture.
Генетический механизм репродукции реализует адаптивный способ разрешения неопределенности.
Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место неопределенность условий существования. Вдруг завтра прилетит метеорит и изменится состав атмосферы?
В связи с этим, двуполое размножение обеспечивает постоянную генерацию новых генетических комбинаций. Мы просто не знаем какая именно генетическая комбинация окажется наиболее приспособленной к завтрашним условиям окружающей среды.
Те генетические комбинации, которые слабо приспособлены к текущим условиям окружающей среды, не должны препятствовать распространению более приспособленных комбинаций. Иными словами, если существует механизм формирования разнообразия генетических комбинаций, то должен существовать и механизм истребления слабо приспособленных генетических комбинаций. Именно поэтому двуполый механизм репродукции не может выполнять свои функции без хищников, назначение которых сводится к истреблению слабо приспособленных генетических комбинаций. Т.е. к селекции. Это как пропалывание грядки.
Зачастую проблема кодовой базы заключается в том, что никто и ничто не выполняет роль этого самого хищника, истребляющего несоответствующие решения. Поэтому больные решения хорошо размножаются.
Robert Martin говорил, что архитектура - это о том, как не надо делать. Иными словами, архитектурное решение - это сокращение количества возможных вариантов. Т.е. архитектура должна выполнять хищнические функции.
Чем отличаются собаки от волков? Волк имеет естественных врагов-хищников, а собаки - нет.
Вместо хищников, процесс селекции собак выполняют выставки и стандарты пород, которые фиксируют желаемые свойства пород.
Выводок, не соответствующий требованиям стандарта породы и допустимым пределам отклонения, отбраковывается и не получает сертификат соответствия. Его рыночная ценность падает, и он не используется заводчиками для репродукции.
По мере возникновения исторических изменений в породе, в стандарт вносятся изменения, требования ужесточаются, что обеспечивает прогресс породы.
Этот же принцип положен в основу Evolutionary Architecture. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.
Роль стандарта породы выполняют fitness functions (функции соответствия, приспособленности). Они позволяют разработчикам измерить степень соответствия старого варианта системы и нового, и выбрать тот, который соответствует требованиям наилучшим образом.
Понимая, что требования fitness functions будут ужесточаться, разработчик всегда стремится увеличивать запас по требованиям , что вынуждает искать его новые решения и постоянно повышать собственный уровень знаний.
Хотя fitness functions выполняют охранные функции, препятствуя деградации свойств системы, главная их ценность заключается не в этом, а в создании благоприятных условий для постоянного развития уровня квалификации специалистов.
Наиболее важными я считаю fitness functions с нагрузочным и объемным тестированием, которые мгновенно выявляют костыльные запросы и побуждают разработчиков изначально закладывать в систему решения с дальним горизонтом развития, например, такие, как CQRS.
Пример реализации fitness functions.
The Architect Elevator
Here’s why enterprise IT is so complex
Enterprise IT is routinely plagued by excessive complexity. It might be subject to the Second Law of Thermodynamics but it’s certainly subject to Gregor’s Law.
👍10👏3🔥2❤1🤔1🤩1
Forwarded from Заметки на инженерных полях
Заметки на полях. Системотехника в забугорьях
Я тут задремал, и пропустил обновление SEBoK!
А оказывается он тут обновился 20.11.2023!
В ближайшее время попробую построить diff между версиями 2.8 и 2.9!
Коротко, что нового:
✔️Добавили статью о реверс-инженерке с применением ажаля на примере беспилотной машинки. Мне кажется будет интересно почитать;
✔️ Заменили статью про безопасность в системотехнике на новую;
✔️Заменили статью с обзором руководства по программной инженерии;
✔️Обновили статью о "Системотехнике движимой потерями" про метод наблюдения за атрибутами качества.
✔️ Обновление статьи про "Самовосстановление" систем (System Resilience)
✔️ Набросали новых сценариев применения самого SEBoK для конечных пользователей. Говорят, что будет более дружелюбен к читателям.
✔️ Всякого по мелочи
Я щасливый! Есть, что почитать на досуге и куда закопаться.
#рабочее #системотехника #стандарты #SEBOK
Я тут задремал, и пропустил обновление SEBoK!
А оказывается он тут обновился 20.11.2023!
В ближайшее время попробую построить diff между версиями 2.8 и 2.9!
Коротко, что нового:
✔️Добавили статью о реверс-инженерке с применением ажаля на примере беспилотной машинки. Мне кажется будет интересно почитать;
✔️ Заменили статью про безопасность в системотехнике на новую;
✔️Заменили статью с обзором руководства по программной инженерии;
✔️Обновили статью о "Системотехнике движимой потерями" про метод наблюдения за атрибутами качества.
✔️ Обновление статьи про "Самовосстановление" систем (System Resilience)
✔️ Набросали новых сценариев применения самого SEBoK для конечных пользователей. Говорят, что будет более дружелюбен к читателям.
✔️ Всякого по мелочи
Я щасливый! Есть, что почитать на досуге и куда закопаться.
#рабочее #системотехника #стандарты #SEBOK
👍2
Forwarded from Заметки на инженерных полях
Заметка на полях. Системотехника в забугорьях.
Откопал курс по основам системной инженерии в MIT. 10 лекций, про то, как в Масачусетсе понимают "Systems engeneering". Да, 2015-й год. Да, не такое свежее. Но вряд ли что-то там радикально меняется в основаниях.
В ближайшее время засяду пересмотреть, и возможно сворую к себе.
Хотелось бы иметь в своём запасе базовый курс по системотехнике, куда можно послать своих товарищей.
На всякий случай там же рядом лежат презентации с этого курса.
#рабочее #системотехника #MIT #учебное
Откопал курс по основам системной инженерии в MIT. 10 лекций, про то, как в Масачусетсе понимают "Systems engeneering". Да, 2015-й год. Да, не такое свежее. Но вряд ли что-то там радикально меняется в основаниях.
В ближайшее время засяду пересмотреть, и возможно сворую к себе.
Хотелось бы иметь в своём запасе базовый курс по системотехнике, куда можно послать своих товарищей.
На всякий случай там же рядом лежат презентации с этого курса.
#рабочее #системотехника #MIT #учебное
MIT OpenCourseWare
Class Videos | Fundamentals of Systems Engineering | Aeronautics and Astronautics | MIT OpenCourseWare
This page provides selected class videos for MIT course 16.842 Fundamentals of Systems Engineering of Fall, 2015.
👍3
Forwarded from Заметки на инженерных полях
Заметка на полях. Моделирование и типы моделей.
Интересная статья на habr-e. Где один из аналитиков рассуждает о типах моделей с которыми приходится сталкиваться и с их особенностями. Главные выводы:
1. Нужно различать когда мы моделируем реальный объект в мире, а когда моделируем представление о реальном объекте. Т.е. можно выделить модели "объектные" и "мнимые". Первое - про штуки, второе - про то, что мы об этих думаем в голове.
2. Моделирование одного и того же объекта, не важно реального или мнимого, можно делать разными способами. Через атрибутирование понятия, через выделения методов относящихся к объекту, через отношения между несколькими объектами. Важно понимать ограничения этих методов моделирования и цели моделирования. Мне кажется, что тут много про методы проектирования
3. Запоминаем как "Отче наш...", что модели предназначены для коммуникации, и важно не то, что мы напишем в модель, а то, что там прочитают. Поэтому писать надо не себе будущему, а "ему" прошлому =)
#идейное #моделирование #boro
Интересная статья на habr-e. Где один из аналитиков рассуждает о типах моделей с которыми приходится сталкиваться и с их особенностями. Главные выводы:
1. Нужно различать когда мы моделируем реальный объект в мире, а когда моделируем представление о реальном объекте. Т.е. можно выделить модели "объектные" и "мнимые". Первое - про штуки, второе - про то, что мы об этих думаем в голове.
2. Моделирование одного и того же объекта, не важно реального или мнимого, можно делать разными способами. Через атрибутирование понятия, через выделения методов относящихся к объекту, через отношения между несколькими объектами. Важно понимать ограничения этих методов моделирования и цели моделирования. Мне кажется, что тут много про методы проектирования
3. Запоминаем как "Отче наш...", что модели предназначены для коммуникации, и важно не то, что мы напишем в модель, а то, что там прочитают. Поэтому писать надо не себе будущему, а "ему" прошлому =)
#идейное #моделирование #boro
Хабр
Типы моделей
Правильно заданный вопрос быстро приводит к правильному ответу. Недавно меня спросили: «Почему стандарты бизнес-анализа сконцентрированы на выявлении требований, но ничего не говорят о превращении...
👍2🔥1
Заметки на инженерных полях
Заметка на полях. Моделирование и типы моделей. Интересная статья на habr-e. Где один из аналитиков рассуждает о типах моделей с которыми приходится сталкиваться и с их особенностями. Главные выводы: 1. Нужно различать когда мы моделируем реальный объект…
у автора есть и другие интересные статьи по моделированию:
https://habr.com/ru/users/maxstroy/
https://habr.com/ru/users/maxstroy/
Хабр
Марк Мельник aka maxstroy
- Пользователь
- Пользователь
Марк Мельник aka maxstroy. Опубликовал 64 статьи на Хабр и оставил 1 504 комментария.
👍1🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
у автора есть и другие интересные статьи по моделированию: https://habr.com/ru/users/maxstroy/
Очень актуальная статья, разъясняющая суть Bounded Context с еще одного ракурса:
https://habr.com/ru/articles/332064/
https://habr.com/ru/articles/332064/
Хабр
Как запутать аналитика. Часть вторая: что такое моделирование предметной области?
В прошлой статье я говорил о заблуждениях, к которым склонны программисты и обещал рассказать про заблуждения, к которым склонны не только программисты, но и каждый из нас. Объект учета и результат...
🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Вот эта картинка из главы "1.4.2.2 Relationship between Requirements Models and Design Models" справочника "Handbook of Requirements Modeling According to the IREB Standard", которая слегка модифицирует оригинальную картинку из известной статьи Twin Peak Model…
Оказывается, у Eric Evans это есть прямым текстом:
💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
Вот что такое DDD одним предложением.
P.S.: Моя благодарность всем участникам дискуссии в @ru_arc_chat
💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
Вот что такое DDD одним предложением.
P.S.: Моя благодарность всем участникам дискуссии в @ru_arc_chat
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Вот эта картинка из главы "1.4.2.2 Relationship between Requirements Models and Design Models" справочника "Handbook of Requirements Modeling According to the IREB Standard", которая слегка модифицирует оригинальную картинку из известной статьи Twin Peak…
👍3🔥2❤1
Forwarded from Russian Association of Software Architects (Ivan)
Коллеги, вы помните, как противоречия в чате канала привели к настолько детальному исследованию вопроса, что по мотивам диалогов возник доклад про SAGA.
Тогда мы непроизвольно использовали диалектический метод познания, известный еще со времен "Диалогов Платона" (и даже раньше). Тогда же родилась идея создать отдельную группу для практикования этого метода в поисках ответов на противоречивые вопросы. Как это модно говорить сегодня - для "баттлов".
Сегодня такая группа была создана: https://news.1rj.ru/str/ru_arc_dialogues
Добавляйтесь, аргументируйте, публикуйте свои противоречивые вопросы.
Тогда мы непроизвольно использовали диалектический метод познания, известный еще со времен "Диалогов Платона" (и даже раньше). Тогда же родилась идея создать отдельную группу для практикования этого метода в поисках ответов на противоречивые вопросы. Как это модно говорить сегодня - для "баттлов".
Сегодня такая группа была создана: https://news.1rj.ru/str/ru_arc_dialogues
Добавляйтесь, аргументируйте, публикуйте свои противоречивые вопросы.
🔥3👍1
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Как-то мимо меня прошло достаточно свежее:
https://www.youtube.com/watch?v=am-HXycfalo
https://www.youtube.com/watch?v=am-HXycfalo
YouTube
Bounded Contexts - Eric Evans - DDD Europe 2020
Domain-Driven Design Europe 2020 - Organised by Aardling (https://aardling.eu/)
https://dddeurope.com
https://newsletter.dddeurope.com/
https://be.linkedin.com/company/domain-driven-design-europe
https://bsky.app/profile/dddeu.bsky.social
https://masto…
https://dddeurope.com
https://newsletter.dddeurope.com/
https://be.linkedin.com/company/domain-driven-design-europe
https://bsky.app/profile/dddeu.bsky.social
https://masto…
👍3
Приглашаю курящих коллег в свой телеграм-канал, посвященный трубкам:
https://news.1rj.ru/str/pipecastle
https://news.1rj.ru/str/pipecastle
👍4🤯3
zaschita_oblachnoy_bazy_personalnyh_dannyh_s_ispolzovaniem_gomomorfnogo.pdf
607.7 KB
Не смог не поделиться
🔥3👍1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Оказывается, у Eric Evans это есть прямым текстом: 💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes. -- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by…
💬 "People's body language can be another source of information: not every dissent can be verbal. It's not infrequent to have people from different hierarchy levels to have different views on apparently the same problem. Shaking heads, or eyes rolling are a clue of conflicting perspectives that haven't been addressed.
Domain-Driven Design has a fantastic tool for resolving these conflicts: it's not "we need a model to solve these issues", it's "we need a model to solve your problem and we need a model to solve your boss’ problem", it would be up to software architects to find the perfect way to interact.
Once again: different needs mean different models."
-- "DDD First 15 years", chapter "Discovering Bounded Contexts with EventStorming — Alberto Brandolini"
Напомню, что границей модели является Bounded Context.
Domain-Driven Design has a fantastic tool for resolving these conflicts: it's not "we need a model to solve these issues", it's "we need a model to solve your problem and we need a model to solve your boss’ problem", it would be up to software architects to find the perfect way to interact.
Once again: different needs mean different models."
-- "DDD First 15 years", chapter "Discovering Bounded Contexts with EventStorming — Alberto Brandolini"
Напомню, что границей модели является Bounded Context.
👍5🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В 2022 году я думал, как хорошо, что в РФ есть такая компания как Яндекс, которая обеспечивает технологическую независимость страны. Как я тогда ошибался. Нет ничего хуже монополии в условиях безальтернативности, которая приводит к полной зависимости от прихоти…
Следом за Яндекс.Плюс, расстаюсь с ВТБ. Причины три:
1. Из-за дефекта в их антифрод-системе, несколько месяцев назад я оказался без доступа к собственным средствам в самый неподходящий момент, когда нужно было срочно перевести средства человеку, который на них рассчитывал. Естественно, в нерабочее время. Естественно, "приходите в офис, когда он откроется, с паспортом и докажите, что Вы - не мошенник", даже если впереди неделя праздников. Причем, никаких подозрительных операций не было - система сработала на ежемесячный перевод за аренду недвижимости.
2. Полгода назад имел неосторожность поинтересоваться в ВТБ кредитом. Такое чувство, будто разместил объявление на самой популярной доске объявлений, - кредитные спамеры одолевают до сих пор, обращаясь ко мне по имени-отчеству. Это все, что нужно знать о дееспособности СБ банков. В принципе, чего еще можно ожидать от несостоявшихся на службе силовиков? Будучи неспособными противостоять на службе равному противнику, они уходят в СБ гражданских компаний выискивать себе противника из числа мирных соискателей, совершая доблестные подвиги по защите своего работодателя от любых проявлений квалификации, путем выискивания в соискателе угроз в виде наличия у него ИП, или второго гражданства, или недостаточно долгой работы на каком-то месте, или в отказе пройти полиграф, или что-то еще им померещиться.
3. Окончательным пределом терпения стало то, что ВТБ самостоятельно, без моего ведома и против моей воли, сменил мне тарифный пакет на Привилегию. При этом поддержка ссылалась на п.4.15 правил комплексного обслуживания, который, если внимательно почитать, был нарушен банком дважды. Я и так этим банком не пользовался, т.к. он малопригоден для ежедневных операций, но ВТБ, видимо, решил, что я должен за такое качество сервиса еще и платить по 5000 руб./месяц, оправдываясь тем, что "есть же акционный период".
Про всякие мелочи в виде дефектов из-за очевидных архитектурных косяков я промолчу.
Поведение монополистов на российском рынке все больше вызывает отторжение.
Все больше хочется пользоваться услугами компаний, которые еще "не зажрались" и борятся за клиента, например, банк БКС.
Альфа остается моим основным банком уже несколько лет. Да, были косяки, были даунтаймы, но с этикой они дружат и не позволяют себе принимать решения вместо меня.
Все больше начинаю осознавать, что конкуренцию на рынке нужно оздоравливать, что нужны меры поддержки малых и средных компаний, что нужно способствовать перетоку с трудового на коммерческий рынок квалифицированных специалистов. Все больше возвращаюсь к идеям, которые я изложил в свое время в этом черновике своего доклада, но пока отложил в долгий ящик.
1. Из-за дефекта в их антифрод-системе, несколько месяцев назад я оказался без доступа к собственным средствам в самый неподходящий момент, когда нужно было срочно перевести средства человеку, который на них рассчитывал. Естественно, в нерабочее время. Естественно, "приходите в офис, когда он откроется, с паспортом и докажите, что Вы - не мошенник", даже если впереди неделя праздников. Причем, никаких подозрительных операций не было - система сработала на ежемесячный перевод за аренду недвижимости.
2. Полгода назад имел неосторожность поинтересоваться в ВТБ кредитом. Такое чувство, будто разместил объявление на самой популярной доске объявлений, - кредитные спамеры одолевают до сих пор, обращаясь ко мне по имени-отчеству. Это все, что нужно знать о дееспособности СБ банков. В принципе, чего еще можно ожидать от несостоявшихся на службе силовиков? Будучи неспособными противостоять на службе равному противнику, они уходят в СБ гражданских компаний выискивать себе противника из числа мирных соискателей, совершая доблестные подвиги по защите своего работодателя от любых проявлений квалификации, путем выискивания в соискателе угроз в виде наличия у него ИП, или второго гражданства, или недостаточно долгой работы на каком-то месте, или в отказе пройти полиграф, или что-то еще им померещиться.
3. Окончательным пределом терпения стало то, что ВТБ самостоятельно, без моего ведома и против моей воли, сменил мне тарифный пакет на Привилегию. При этом поддержка ссылалась на п.4.15 правил комплексного обслуживания, который, если внимательно почитать, был нарушен банком дважды. Я и так этим банком не пользовался, т.к. он малопригоден для ежедневных операций, но ВТБ, видимо, решил, что я должен за такое качество сервиса еще и платить по 5000 руб./месяц, оправдываясь тем, что "есть же акционный период".
Про всякие мелочи в виде дефектов из-за очевидных архитектурных косяков я промолчу.
Поведение монополистов на российском рынке все больше вызывает отторжение.
Все больше хочется пользоваться услугами компаний, которые еще "не зажрались" и борятся за клиента, например, банк БКС.
Альфа остается моим основным банком уже несколько лет. Да, были косяки, были даунтаймы, но с этикой они дружат и не позволяют себе принимать решения вместо меня.
Все больше начинаю осознавать, что конкуренцию на рынке нужно оздоравливать, что нужны меры поддержки малых и средных компаний, что нужно способствовать перетоку с трудового на коммерческий рынок квалифицированных специалистов. Все больше возвращаюсь к идеям, которые я изложил в свое время в этом черновике своего доклада, но пока отложил в долгий ящик.
👏21👍5💯4🤣2🔥1
High Coupling в действии:
😁3👍1
Forwarded from КБ
This media is not supported in your browser
VIEW IN TELEGRAM
Вкачал всё в удачу
😁17
Forwarded from bob
В продолжение этой животоепещущей истории https://youtu.be/qOtioVb2RLA?si=FMmgHM3ibgglmlKs
YouTube
Войны Пентагона - Создание "Бредли"
🔥6😁3🤣1