Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Заголовок у статьи традиционный, полусектантский, про микросервисы. Ладно.
Введение у статьи интересное, разумное и обещающее полезный материал.
Содержание у статьи, хм, отсутствует.
О чём статья, может я не разглядел?
Введение у статьи интересное, разумное и обещающее полезный материал.
Содержание у статьи, хм, отсутствует.
О чём статья, может я не разглядел?
Используйте MVVM, SOLID, CQRS и тогда все будет хорошо, но это не точно.
Спасибо за комментарий. Обновим и добавим конкретики про использование.
В данной статье просто не хотелось уходить в детали решения того как базово применять данные подходы. Таких статей на мой взгляд много. Хотелось сделать именно акцент на том что применять проектирование даже и особенно на этапе MVP нужно! Что нужно с точки зрения бизнеса не забывать об архитектуре даже в те моменты, когда хочется быстро «накалбасить» решение и зарелизить что бы проверить гипотезы.
Но прочитав комментарии соглашусь что надо добавить больше тех. информации с обоснованиями в содержание.
Но прочитав комментарии соглашусь что надо добавить больше тех. информации с обоснованиями в содержание.
Хотелось сделать именно акцент на том что применять проектирование даже и особенно на этапе MVP нужно!
Ну вот не факт, с моей точки зрения. Есть вообще всякие термины типа throw-away prototype. И иногда, полагаю, действительно можно сделать первую версию абы как. Зависит от ситуации.
А вот сразу продумывать архитектуру может означать удариться в микросервисы, или даже, прости господь, в блокчейн. За всё это платить придётся сразу, а ценности продукта в итоге может и не получиться.
Вот тут уже интересно=). Хочу задать пару вопросов:
1)Почему для вас фраза «продумывать архитектуру» ассоциируется в первую очередь с блокчейном и микросервисами а не с бизнесом к примеру? =) Какую для вас ценность несёт термин «достаточная» проработка архитектуры?
2)Да, прототипирование, в том числе и rapid prototyping существуют и имеют вполне себе осмысленное право на существование. При этом, хочу обратить ваше внимание что так же существует Эволюционное прототипирование. Мы к примеру так же использовали на мой взгляд удачно быстрое прототипирование в кейсе https://koniglabs.ru/case_study/1-2stundeuben%e2%80%8c/. Но при этом я не скажу что это Minimum Viable Product. Может вопрос в целях использования прототипирования? =)
Как пример: Можно сделать UX прототипирование достаточно быстро и без строчки кода. При этом цель тут понятная- изучение пользовательского опыта. Но глупо ставить к примеру целью UX прототипирования: Понять концепцию решения сложной математической задачи.
1)Почему для вас фраза «продумывать архитектуру» ассоциируется в первую очередь с блокчейном и микросервисами а не с бизнесом к примеру? =) Какую для вас ценность несёт термин «достаточная» проработка архитектуры?
2)Да, прототипирование, в том числе и rapid prototyping существуют и имеют вполне себе осмысленное право на существование. При этом, хочу обратить ваше внимание что так же существует Эволюционное прототипирование. Мы к примеру так же использовали на мой взгляд удачно быстрое прототипирование в кейсе https://koniglabs.ru/case_study/1-2stundeuben%e2%80%8c/. Но при этом я не скажу что это Minimum Viable Product. Может вопрос в целях использования прототипирования? =)
Как пример: Можно сделать UX прототипирование достаточно быстро и без строчки кода. При этом цель тут понятная- изучение пользовательского опыта. Но глупо ставить к примеру целью UX прототипирования: Понять концепцию решения сложной математической задачи.
Ну нельзя же так обламывать. Внимательно и долго читал введение, только приготовился прочитать о том как конкретно удалось решить проблему с использованием CQRS, приготовился увидеть как красиво все разложили по доменам вместо "Большого кома грязи", собирался увидеть как распутали сложную запутанную логику, увидеть за счет чего удалось переиспользовать фичи, и вместо всего это как то резко свелось к одному рекламному обзацу "Мы взяли CQRS и стало хорошо". :)
Atreides07, DmitriyTitov, MrAwesome, NickPasko спасибо еще раз за ваши комментарии. Решили к ним прислушаться и немного доработать статью, добавив и раскрыв более подробно «Что сделали мы», показав схему архитектуры самого приложения, а также привести примеры того, как внедрить такое разбиение у себя в проекте.
Будем рады узнать ваше мнение :)
Будем рады узнать ваше мнение :)
А могли бы чуть подробней рассказать про механизм синхронизации, вы команды из Local Db перегоняете в Server Db и обратно переодически?
Конечно, спасибо за вопрос:
Как только интернет соединение появляется- ПО проверяет автоматом обновления. Если надо обновить, то пользователю поступает запрос с возможностью отложить обновление определённое кол-во раз. После того как пользователь соглашается, то происходит обновление по пакетам асинхронно.
При этом есть альтернативное решение, но более дорогое с точки зрения реализации. Не спрашивать у пользователя хочет ли он обновится, а просто обновлять пакетами в бекграунде, а потом уже говорить пользователю что всё обновлено и делать свап данных.
Ответил на вопрос?
Как только интернет соединение появляется- ПО проверяет автоматом обновления. Если надо обновить, то пользователю поступает запрос с возможностью отложить обновление определённое кол-во раз. После того как пользователь соглашается, то происходит обновление по пакетам асинхронно.
При этом есть альтернативное решение, но более дорогое с точки зрения реализации. Не спрашивать у пользователя хочет ли он обновится, а просто обновлять пакетами в бекграунде, а потом уже говорить пользователю что всё обновлено и делать свап данных.
Ответил на вопрос?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CQRS и микросервисы в продуктовой разработке