emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. – Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
3.48K subscribers
119 photos
15 videos
22 files
1.14K links
Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, Extreme Programming, SDLC, Agile, etc.

Chat: https://news.1rj.ru/str/emacsway_chat

Persistence: https://dckms.github.io/system-architecture/
Download Telegram
Сейчас в кулуарах российского архитектурного сообщества обсуждается вопрос организации Reference Application и Reference Architectures.

Если кто не в курсе - это такая эталонная демонстрация, создаваемая с целью демонстрации архитектурных решений на живом примере. Но лучше один раз увидеть - в качестве примера можно посмотреть:

Пример DDD/MSA Reference Application:
- https://github.com/dotnet-architecture/eShopOnContainers

Пример Reference Architecture:

"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
- https://community.opengroup.org/archimate-user-community/home/-/issues/8

Archi Banking Group: Combining the BIAN Reference Model, ArchiMate® Modeling Notation, and the TOGAF® Framework:
- https://publications.opengroup.org/y201
- https://publications.opengroup.org/y201m

И т.п.

Я нередко использую Reference Applications в работе, для демонстрации типовых архитектурных решений разработчикам. Могу заметить, что полностью завершенные эталонно-демонстрационные приложения мне неизвестны, поэтому, приходится обращаться к ним в качестве демонстрационных примеров разрозненно и фрагментарно, "выкусывая" из них качественно организованные аспекты и игнорируя остальные. У меня даже сформировался некий "путеводитель", указывающий в каком демонстрационном приложении лучше смотреть реализацию того, либо иного, архитектурного аспекта.

Не хватает единого и завершенного демонстрационного приложения, которое сделало бы такой "путеводитель" ненужным. По всей видимости, ситуация назрела для обсуждения её решения.

Если кому эта тема интересна, и кто-то хочет её обсудить, и имеет возможность принять участие в создании Reference Application/Architectures, обращайтесь ко мне в личку ( @emacsway ) за инвайтом в группу обсуждения. Вместе попробуем найти решение этого вопроса.
👍14
Коротко о самой сути термина Technical Debt:

📝 "Asking "is something technical debt" is usually uninteresting. The metaphor's value is comparing paying interest vs principal. We judge debt of $1K differently if we are paying $1/month to service it vs $100/month"

-- Martin Fowler, https://twitter.com/martinfowler/status/1517152168775614473?t=BMpST8vXSLBnY36k9o-lUg&s=19

Подробнее по этой теме здесь.
"Multi-cloud: From Buzzword to Decision Model" by Gregor Hohpe
- https://architectelevator.com/cloud/multi-cloud-decision-model/

Architects aren’t there to make all decisions. They help others make better decisions by sharing models. Let’s do that for a major enterprise decision: whether to cloud or multi-cloud.

📝 "Architects aren’t the smartest people in the room. Their primary job is to make everyone else smarter, for example, by getting folks to see more dimensions."

Хорошая статья.

#SoftwareArchitecture
👍8
Мне приходилось слышать о ряде неудачных кейсов по внедрению DDD. Интересно послушать ваш опыт внедрения DDD. Был ли он успешным? Каким образом удалось преодолеть сопротивление? Был ли он неудачным? По каким причинам?
🔥3👍1🤔1
Давно не писал в канал, не мог найти времени, а все от того, что параллельно работаем над такими вещами, как:
- референс-архитектуры, в том числе микросервисные, в том числе ддд-compliant (детали тут: https://news.1rj.ru/str/emacsway_log/888)
- возрождение архитектурных ката, попробуем перезапустить с @Kirill_vet
- российская сертификация/база знаний в области разработки и проектирования (от сообщества для сообщества). Понятно, что нет такого понятия, как «российская специфика», но есть определенный базис, который нужен и хорошо, если мы сможем его давать внутри страны 👍получится - хорошо, не получится - чему-то научимся :)
- ddd проникает во все большее число компаний, растет интерес к применению ddd для отображения в орг структуру. Чему я несказанно рад, потому что при проектировании микросервисов так или иначе всегда строили модель предметной области, а вот предложение перенести эту модель в орг структуру и бизнес-архитектуру принималось через раз (где принималось, те понимают о чем я 😉). Готовлю выступление «оргдизайн через ddd». Кстати, это буквально воплощение закона Конвея.
- со дня на день стартует подготовка к archdays. Оффлайн🤞, наверное все же с онлайном, ибо странно не использовать этот канал совсем. Уже есть заявки, ждем еще 👀
👍6🤔2🔥1
Пошла жара вокруг ДДД. Имхо когда мы говорим о какой-то практике, нужно четко разделять:
1. Академическую часть
2. Приклад
3. Контекстно-зависимое применение

Поясню на примере ДДД.

Академическая часть - это Эванс, Вернон, работы о самом ДДД, теория сложных адаптивных систем, моделирование, системное мышления и проячее. Академическая часть нужна для того чтобы:
- развивать фундаментальные основы, независимо от приклада
- обучать прикладным вещам (да, для этого важно понимать, на чем они основаны)
2. Приклад. Например, - дизайн организационной структуры, принятие управленческих решений на основе типов доменов (что инхаус разрабатывать, что отдать на аутсорс), проектирование микросервисного решения
3. Контексто-зависимый приклад - например, Банк, CRM, ритейл, Поиск. Для применения здесь не нужно даже знать терминологию ДДД, и даже вообще знать что есть какое-то ДДД, но тому кто будет проектировать или строить модели, проводить совместное исследование домена, безусловно, нужны знания и на академическом и на прикладном уровне (а вот контекстно-зависимый приклад уже не так важен, его нужно структурировать усилиями участников совместной практики).

И так с любой практикой, имхо. Есть популярный узкоспециализированный приклад, есть принципы и основы на которых он построен и их знание позволяет подстраиваться под любые специализации в рамках области определения и есть еще более фундаментальные основы, которые дают понимание самых базовых принципов.

Менеджмент становится намного проще при знании мат аппарата теории массового обслуживания (теории очередей) просто потому, что знание что там в числителе, что в знаменателе, что от чего зависит позволяет быстро оценить зависимости по переменным для любого контекста. Это не обязательно, конечно, и не всем нужно, но для обучения менеджменту (в моем понимании - и архитектуре), для понимания как работать с потоком создания ценности, это имхо прям must have знания.

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

Буду рад обсудить в коментах.
👍13🤔1
Forwarded from Maxim Smirnov
В момент выхода версии 9.2 TOGAF развивающая его The Open Group анонсировал свое намерение превратить TOGAF в открытую расширяемую библиотеку. В 10-ой версии это практически реализовалось. PDF-ы скачать можно, но их довольно много и работать с ними не очень удобно
Собственно, короткая заметка о выходе TOGAF10 у меня в блоге https://mxsmirnov.com/2022/04/28/togaf-10/
👍3
Некоторые шутники уже меня спрашивают:
- Потребуется ли миграция архитектурных репозиториев на новую версию TOGAF-10 с предыдущих версий

Шутка, безусловно, веселая, но как в любой шутке в ней есть доля чего-то большего. Во-первых, некоторые изменения и в метамодели, и в содержании стандарта в целом всё же есть. Насколько существенные - это уже другой вопрос Таблички с изменениями можно посмотреть в Appendix A An Introduction to the TOGAF® Standard, 10th Edition. Во-вторых, The Open Group, как мне представляется, действует вполне осознанно, пытаясь сохранить свои лидирующие позиции центра компетенций по архитектуре предприятия. Посмотрев какой отклик получил O-AA, а до этого и DPBOK, сейчас они возвращают наше внимание к TOGAF. И если кого-то и что-то не устраивало и не устраивает в основном стандарте, то ответы и уточнения теперь придется искать всё равно в TOGAF, но уже в TOGAF Series Guides или в TOGAF Library, куда попал, например, стандарт IT4IT и пр.
Forwarded from Event Storming
Обновил дизайн http://storming.ru 😍
Скоро туда весь накопившийся контент начну перетаскивать.
👍8
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
📝 "A Bounded Context is not a purely logical (language consistency, unity of purpose) or physical (code separation, deployment unit) concept. It's an obligation to maintain integrity between those views." -- Alberto Brandolini https://twitter.com/ziobran…
Возвращаясь к определению Bounded Context от Alberto Brandolini:

"A Bounded Context is not a purely logical (language consistency, unity of purpose) or physical (code separation, deployment unit) concept. It's an obligation to maintain integrity between those views."

, невольно начинаю думать, что перевод "Ограниченный" полисемантического слова "Bounded" , возможно, был выбран не совсем удачно. Есть предположение, что термин "Связанный" контекст лучше передает смысл.

На такую же мысль меня наводят и фразы:

"Bounded context means different models of the same thing (e.g., books, customers, etc.) and is represented by models and software that implement those models."

Иными словами, Bounded Context образует связанность между программируемой моделью и её сущностью реального мира.

Следующие две фразы трактуют термин "bounded" именно как "связанный":

"How to minimize inter-bounded context dependencies?"

"The components of complex systems are bounded sub-systems or agents that adapt or learn when they interact."

А следующая фраза говорит о том, чем именно "связаны" (т. е. скованы) команды. Кстати, слово "скованный" - один из вариантов перевода термина "bounded".

"The scope of each team was bounded by their business line and their products."

Следующие две фразы говорят о том, каким именно образом происходит "сковывание":

"Bounded contexts aligned with data source domains, such as fixed-income trading or consumer lending"

"Bounded contexts aligned with consumption domains, such as accounting or liquidity"

Эта идея немного рушится фразой:

"A bounded context is the boundary for the meaning of a model."

Но тут можно вспомнить, что термин "boundary" полисемантический, и означает также "межу" или "грань". Обратите внимание на фразу "boundary for the meaning". Не "boundary of subsystem", а "boundary for the meaning", что привязывает реализацию (solution space) к её "предметному смыслу" (meaning of a model). Т.е. главное не ограничить абы как подсистему, а привязать её к доменному толкованию. Именно это Alberto Brandolini и назвал "obligation to maintain integrity".

"bounded contexts delimit the applicability of domain models. As such, the bounded context is within the solution space."

Все цитаты из AO-S.

Что думаете? Какие мысли по этому поводу?
👍9
Чем отличается "validation" от "verification", одним предложением:

📝 "The validation process determines that the "right product is built". The verification process determines that the "product is built right".
-- "ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes"
👍17
Forwarded from Я Математик
Дискретная математика. Практикум по теории множеств

Множества. Операции над множествами
Операции над множествами
Решение теоретико-множественных соотношений
Решение уравнений относительно множеств
Взаимное расположение множеств
Включения и равенства
Множества. Соответствие. Мощность. Примеры. Понятие функции
Взаимнооднозначное соотношение, биекция
Функции. Способы задания. Отношения
Графики
Решение уравнений относительно графиков
Соответствия
Бинарные отношения
Факторизация отображений

https://www.youtube.com/playlist?list=PLDrmKwRSNx7LJfbF6FZXBBuo3XCCAGIj-
👍4🔥2
Forwarded from Я Математик
Яндекс Практикум запустил бесплатный тренажёр по основам математики для цифровых профессий

Сервис онлайн-обучения цифровым профессиям Яндекс Практикум запустил бесплатный тренажёр по основам математики для цифровых профессий. С его помощью можно повторить школьную программу и освоить базовые математические навыки для работы продакт-менеджером, разработчиком, аналитиком или специалистом по Data Science.

Тренажёр состоит из 5 модулей: «Числа», «Дроби», «Алгебра», «Множества и логика» и «Комбинаторика».

В каждом модуле от 15 до 20 уроков.

Длительность прохождения одного модуля — 20-30 часов.

Вы научитесь:

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

Приступить к прохождению тренажёра и изучить подробности можно по ссылке.
👍7