Ну по сути внутри 3 файла, в котором описаны все нужные штуки. Первый yaml с структурой вопросов: сам вопрос, его сложность, массив из вариантов ответа, верный ответ и объяснение почему так:
questions:
- id: 1
difficulty: easy
type: mcq
question: "Какой протокол используется для асинхронной передачи сообщений в реактивных архитектурах?"
options:
- "HTTP/REST"
- "Apache Kafka"
- "FTP"
- "SMTP"
correct: 1
explanation: "Apache Kafka обеспечивает надежную асинхронную передачу сообщений между сервисами в реактивных системах."
Второй маркдаун, с политикой обработки данных (потому что это важно)
И третий yaml с текстами самого бота: что отвечать на команды.
Делал для своего удобства, чтобы опечатки не править через код :)
Роли, это классно, матрицы и оформление документов по PMBOK, это вообще высший пилотаж
не задумывался об этом, спасибо за комплимент. Приятно слышать :)
в маленькой компании невозможен да и ненужен
я бы ориентировался на количество продуктов/систем/сервисов. Плюс тут речь не об размере компании, а о ее бизнес архитектуре. Согласен, что это нужно точно не везде.
Но архитектурный комитет и обсуждение архитектуры это не одно и тоже.
абсолютно верно. тут скорее обсуждение в рамках портфелей проектов
Но много ли компаний могут похвастаться подобной численностью, и простите, а какая проблема решается?
компаний таких много. более того: численность не решает - компания может использовать аутстаф и иметь огромный портфель проектов. Знаю коллег по рынку, которые имеют численность меньше, но архком. А есть и численность больше и тоже имеют архком. Про эффективность в их компаниях не буду отвечать и называть их не буду - ожидаю, что они придут сами :)
Чистая архитектура — это именно архитектура, а не дизайн. Разница между дизайном и архитектурой состоит в том, что дизайн затрагивает только часть системы, а архитектура охватывает всю систему, в том числе, помимо организации кодовой базы, она охватывает еще работу с внешними системами и описание процессов, документацию, инфраструктуру и так далее.
Так что да, архитектура должна формализировать, в том числе, и каденции в команде и так далее)
Тут речь не про изобретение своей RDBSM, а про органичное использование возможностей. Например: что делать, если вам нужно отправить уведомление пользователю, но при этом транзакция в конце откатывается? Это явно не RDBSM решать.
Вы можете заметить, что для этого есть паттерн Outbox, но где в чистой архитектуре его место? И где в чистой архитектуре выполнять инфраструктурную задачу "после успешной бизнес транзакции отправить уведомление"?
Мы пошли простым путем: uow был обозначением бизнес транзакции - т.е полноценного бизнес значимого действия. По сути post-commit - это место, где можно отправить уведомление.
За скобки вынесем приемы DDD - это не тема статьи)
Важная оговорка - если следовать терминам, то и маппер читается двояко. Если поднимать статьи умных дядек - так все совсем по другому.
Не стоит упарываться строго по терминам. "Трекалка состояния" эволюционировала естественным образом спустя пол года: мы просто поняли, что это отличное место для ослабления связности и мониторинга. При этом мы не нарушили слоистость - просто дали больше возможностей компоненту, который нам удобен. Более того: мы отказались, в последствии, от трекания состояния в kv-storage и перешли к commit-rollback RDBSM.
Что нам это дало? Далее мы смогли в сервисы уносить просто куски кода и переписывать маленькую часть - маппер.
А что касается идеи - зачастую, в силу разных причин и, особенно, в заказной разработке есть негатив в сторону заказчика. Его можно решать как процессно, так и технически.
В целом - да. Получалось так, что пишется спека, но корнер кейсы и rollback - нет. В итоге разработчики начали дудосить вопросами аналитиков и случился перегруз)
Холивара не было - разраб все так же остался на своем месте в "пищевой цепочке". Просто архитектура заставляла людей думать больше. В сравнении с подходом "ну мы опишем основные требования - сделай хорошо, не делай плохо" - это вызвало недовольство.
На самом деле мы внутри это не называли прямо "чистой архитектурой". Тут скорее смысл о том, что технические нюансы заставляют работать процессы вокруг. В том числе благодаря вовлечению бизнеса и то, что он понимает почему ему задают вредные вопросы.
Например в статье подробно не освещаются ADR, архитектурный документ проекта, каденции команды и т.д. При этом в это всем участвует бизнес, видит как оно работает и получается подтверждение при помощи метрик)
Информация
В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Технический директор, Архитектор программного обеспечения
Приятно слышать, что кому то помог!
Я как владелец канала получил с бота очень хорошие продуктовые метрики :)
Ну по сути внутри 3 файла, в котором описаны все нужные штуки. Первый yaml с структурой вопросов: сам вопрос, его сложность, массив из вариантов ответа, верный ответ и объяснение почему так:
Второй маркдаун, с политикой обработки данных (потому что это важно)
И третий yaml с текстами самого бота: что отвечать на команды.
Делал для своего удобства, чтобы опечатки не править через код :)
не задумывался об этом, спасибо за комплимент. Приятно слышать :)
я бы ориентировался на количество продуктов/систем/сервисов. Плюс тут речь не об размере компании, а о ее бизнес архитектуре. Согласен, что это нужно точно не везде.
абсолютно верно. тут скорее обсуждение в рамках портфелей проектов
компаний таких много. более того: численность не решает - компания может использовать аутстаф и иметь огромный портфель проектов. Знаю коллег по рынку, которые имеют численность меньше, но архком. А есть и численность больше и тоже имеют архком. Про эффективность в их компаниях не буду отвечать и называть их не буду - ожидаю, что они придут сами :)
Оно возможно даже в рамках команды. Просто масштаб меньше, процессы проще, ролей тоже будет сокращенное количество.
А формат ADR (который вынесен отдельно) позволяет принимать ссылку на хабр как зафиксированное решение на уровне команды :)
Что касается размытия ответственности - эту проблему решает RACI матрица.
Чистая архитектура — это именно архитектура, а не дизайн. Разница между дизайном и архитектурой состоит в том, что дизайн затрагивает только часть системы, а архитектура охватывает всю систему, в том числе, помимо организации кодовой базы, она охватывает еще работу с внешними системами и описание процессов, документацию, инфраструктуру и так далее.
Так что да, архитектура должна формализировать, в том числе, и каденции в команде и так далее)
Коллега, вы очень круто подхватили мысль.
Но я добавлю: т.к у нас было легаси мы пошли через анемичную модель. Это еще интереснее путь)
Тут речь не про изобретение своей RDBSM, а про органичное использование возможностей. Например: что делать, если вам нужно отправить уведомление пользователю, но при этом транзакция в конце откатывается? Это явно не RDBSM решать.
Вы можете заметить, что для этого есть паттерн Outbox, но где в чистой архитектуре его место? И где в чистой архитектуре выполнять инфраструктурную задачу "после успешной бизнес транзакции отправить уведомление"?
Мы пошли простым путем: uow был обозначением бизнес транзакции - т.е полноценного бизнес значимого действия. По сути post-commit - это место, где можно отправить уведомление.
За скобки вынесем приемы DDD - это не тема статьи)
Спасибо за комментарий! Аргументы разумные.
Важная оговорка - если следовать терминам, то и маппер читается двояко. Если поднимать статьи умных дядек - так все совсем по другому.
Не стоит упарываться строго по терминам. "Трекалка состояния" эволюционировала естественным образом спустя пол года: мы просто поняли, что это отличное место для ослабления связности и мониторинга. При этом мы не нарушили слоистость - просто дали больше возможностей компоненту, который нам удобен. Более того: мы отказались, в последствии, от трекания состояния в kv-storage и перешли к commit-rollback RDBSM.
Что нам это дало? Далее мы смогли в сервисы уносить просто куски кода и переписывать маленькую часть - маппер.
Что касается репозитория - это не только мое мнение, но и https://martinfowler.com/eaaCatalog/repository.html
А что касается идеи - зачастую, в силу разных причин и, особенно, в заказной разработке есть негатив в сторону заказчика. Его можно решать как процессно, так и технически.
В целом - да. Получалось так, что пишется спека, но корнер кейсы и rollback - нет. В итоге разработчики начали дудосить вопросами аналитиков и случился перегруз)
Холивара не было - разраб все так же остался на своем месте в "пищевой цепочке". Просто архитектура заставляла людей думать больше. В сравнении с подходом "ну мы опишем основные требования - сделай хорошо, не делай плохо" - это вызвало недовольство.
Поддержу твой поинт)
На самом деле мы внутри это не называли прямо "чистой архитектурой". Тут скорее смысл о том, что технические нюансы заставляют работать процессы вокруг. В том числе благодаря вовлечению бизнеса и то, что он понимает почему ему задают вредные вопросы.
Например в статье подробно не освещаются ADR, архитектурный документ проекта, каденции команды и т.д. При этом в это всем участвует бизнес, видит как оно работает и получается подтверждение при помощи метрик)