D
оно меня пугает
Size: a a a
2020 November 21
V
Если вы задумаете писать архитектуру с нуля, используя зонтичные приложения, станете ли вы убирать взаимодейтсвия с бд в отдельное приложение? Читал тут вот эту статью: https://medium.com/@cedric_paumard/how-to-build-multiple-web-apps-with-elixir-thanks-to-umbrella-part-2-set-up-the-project-800d6d731dbd - человек предлагает так и сделать. И я подумал: как тогда тесты писать? Так или иначе бизнес-сайд приложения будет тесно связан с базой, не мокать же всё.
И работу с сетью вынести в отдельное приложение, да? И работу с файлами тоже? И с stdin/stdout?
VS
шаблон builder такой подход
обычно называют
обычно называют
T
V
И работу с сетью вынести в отдельное приложение, да? И работу с файлами тоже? И с stdin/stdout?
Ну нет. Просто вынести общую экто часть в отдельный зонтик кажется логичной идеей.
T
Но с тестами у меня всё ещё много вопросов...
VS
тут недавно до упаду
ножиками кидались -
записывать видео обучалки
или нет.
Вопрос - зонтик, не зонтик,
мне кажется, из той же серии.
Пофиг, как удобно - так и делай.
ножиками кидались -
записывать видео обучалки
или нет.
Вопрос - зонтик, не зонтик,
мне кажется, из той же серии.
Пофиг, как удобно - так и делай.
T
тут недавно до упаду
ножиками кидались -
записывать видео обучалки
или нет.
Вопрос - зонтик, не зонтик,
мне кажется, из той же серии.
Пофиг, как удобно - так и делай.
ножиками кидались -
записывать видео обучалки
или нет.
Вопрос - зонтик, не зонтик,
мне кажется, из той же серии.
Пофиг, как удобно - так и делай.
Так вот непонятно, удобно или нет. Я ж пока не начал.
VS
переползти с одного на другой - дело пары часов,
так что мучиться философией точно не стоит
так что мучиться философией точно не стоит
V
Ребята, а у кого-то здесь есть опыт дизайна ядра финансовых систем?
Учёт средств, движение по счетам и прочее.
Учёт средств, движение по счетам и прочее.
Есть небольшой. Сформулируй вопрос.
V
Ну нет. Просто вынести общую экто часть в отдельный зонтик кажется логичной идеей.
Общую для чего?
T
V
Общую для чего?
У нас сейчас одна база обслуживает два приложения. Внутреннее и для клиентов. На рельсах. Одно приложение, точнее, просто код храним зонтично, в разных папках. Мы подумываем переписать на эликсире.
V
Ну нет. Просто вынести общую экто часть в отдельный зонтик кажется логичной идеей.
Логично отделять
- то что может быть реюзнуто в нескольких местах
- то, что может инкапсулировать в себе некую часть бизнес- или инфраструктурной логики (S из SOLID)
Персистенция же сама по себе не является по умолчанию ни первым, ни вторым.
- то что может быть реюзнуто в нескольких местах
- то, что может инкапсулировать в себе некую часть бизнес- или инфраструктурной логики (S из SOLID)
Персистенция же сама по себе не является по умолчанию ни первым, ни вторым.
V
У нас сейчас одна база обслуживает два приложения. Внутреннее и для клиентов. На рельсах. Одно приложение, точнее, просто код храним зонтично, в разных папках. Мы подумываем переписать на эликсире.
На более глубоком логическом уровне в ваших приложениях существуют данные. Именно данные, их структура, правила их трансформации (из исходных в производные) и определяют одно у вас приложение или два. Если у вас в этой одной базе данные организованы так, что их логически нельзя разделить на "внутренние" и "для клиентов" - то у вас не два приложения, а одно, просто имеет два разных UI.
Например, в интернет-магазине есть личный кабинет клиента и админка менеджера по отправке. UI разные, но они оба делают выборку по заказам клиентов.
Как это может выглядеть в зонтичном проекте (по трёхтировой схеме):
application содержит контроль инвариантов согласно бизнес-правилам
persistence - низкоуровневый инфраструктурный слой, экто там или что-то ещё
customer_ui и admin ходят в application за чтобы сделать write или read, в persistence напрямую не ходят.
Вот оно как бы просто в теории, а на практике обнаружится, что админке нужно делать какие-то свои выборки, а лк клиента - свои. И в application/persistence начнут появляться методы для этих выборок. А потом, спустя N месяцев уже непонятно будет, зачем существуют те или иные методы. В репозиториях будет по 10 тысяч строк. И тогда начнёшь думать, что может и лучше чтобы админка и лк клиента сами ходили в персистенцию - так хоть понятно было бы, какой код за какой кусок логики отвечает.
Так что ответ зависит от размера приложения. Можно и так и эдак. Первичны всегда данные - если их нельзя логически разделить на две разных базы - у вас одно приложение, а не два.
Например, в интернет-магазине есть личный кабинет клиента и админка менеджера по отправке. UI разные, но они оба делают выборку по заказам клиентов.
Как это может выглядеть в зонтичном проекте (по трёхтировой схеме):
apps
customer_ui
admin_ui
application
persistence
application содержит контроль инвариантов согласно бизнес-правилам
persistence - низкоуровневый инфраструктурный слой, экто там или что-то ещё
customer_ui и admin ходят в application за чтобы сделать write или read, в persistence напрямую не ходят.
Вот оно как бы просто в теории, а на практике обнаружится, что админке нужно делать какие-то свои выборки, а лк клиента - свои. И в application/persistence начнут появляться методы для этих выборок. А потом, спустя N месяцев уже непонятно будет, зачем существуют те или иные методы. В репозиториях будет по 10 тысяч строк. И тогда начнёшь думать, что может и лучше чтобы админка и лк клиента сами ходили в персистенцию - так хоть понятно было бы, какой код за какой кусок логики отвечает.
Так что ответ зависит от размера приложения. Можно и так и эдак. Первичны всегда данные - если их нельзя логически разделить на две разных базы - у вас одно приложение, а не два.
T
V
На более глубоком логическом уровне в ваших приложениях существуют данные. Именно данные, их структура, правила их трансформации (из исходных в производные) и определяют одно у вас приложение или два. Если у вас в этой одной базе данные организованы так, что их логически нельзя разделить на "внутренние" и "для клиентов" - то у вас не два приложения, а одно, просто имеет два разных UI.
Например, в интернет-магазине есть личный кабинет клиента и админка менеджера по отправке. UI разные, но они оба делают выборку по заказам клиентов.
Как это может выглядеть в зонтичном проекте (по трёхтировой схеме):
application содержит контроль инвариантов согласно бизнес-правилам
persistence - низкоуровневый инфраструктурный слой, экто там или что-то ещё
customer_ui и admin ходят в application за чтобы сделать write или read, в persistence напрямую не ходят.
Вот оно как бы просто в теории, а на практике обнаружится, что админке нужно делать какие-то свои выборки, а лк клиента - свои. И в application/persistence начнут появляться методы для этих выборок. А потом, спустя N месяцев уже непонятно будет, зачем существуют те или иные методы. В репозиториях будет по 10 тысяч строк. И тогда начнёшь думать, что может и лучше чтобы админка и лк клиента сами ходили в персистенцию - так хоть понятно было бы, какой код за какой кусок логики отвечает.
Так что ответ зависит от размера приложения. Можно и так и эдак. Первичны всегда данные - если их нельзя логически разделить на две разных базы - у вас одно приложение, а не два.
Например, в интернет-магазине есть личный кабинет клиента и админка менеджера по отправке. UI разные, но они оба делают выборку по заказам клиентов.
Как это может выглядеть в зонтичном проекте (по трёхтировой схеме):
apps
customer_ui
admin_ui
application
persistence
application содержит контроль инвариантов согласно бизнес-правилам
persistence - низкоуровневый инфраструктурный слой, экто там или что-то ещё
customer_ui и admin ходят в application за чтобы сделать write или read, в persistence напрямую не ходят.
Вот оно как бы просто в теории, а на практике обнаружится, что админке нужно делать какие-то свои выборки, а лк клиента - свои. И в application/persistence начнут появляться методы для этих выборок. А потом, спустя N месяцев уже непонятно будет, зачем существуют те или иные методы. В репозиториях будет по 10 тысяч строк. И тогда начнёшь думать, что может и лучше чтобы админка и лк клиента сами ходили в персистенцию - так хоть понятно было бы, какой код за какой кусок логики отвечает.
Так что ответ зависит от размера приложения. Можно и так и эдак. Первичны всегда данные - если их нельзя логически разделить на две разных базы - у вас одно приложение, а не два.
Оп, благодарю за столь подробный ответ :) Порефлексирую над этим на досуге
LL
V
На более глубоком логическом уровне в ваших приложениях существуют данные. Именно данные, их структура, правила их трансформации (из исходных в производные) и определяют одно у вас приложение или два. Если у вас в этой одной базе данные организованы так, что их логически нельзя разделить на "внутренние" и "для клиентов" - то у вас не два приложения, а одно, просто имеет два разных UI.
Например, в интернет-магазине есть личный кабинет клиента и админка менеджера по отправке. UI разные, но они оба делают выборку по заказам клиентов.
Как это может выглядеть в зонтичном проекте (по трёхтировой схеме):
application содержит контроль инвариантов согласно бизнес-правилам
persistence - низкоуровневый инфраструктурный слой, экто там или что-то ещё
customer_ui и admin ходят в application за чтобы сделать write или read, в persistence напрямую не ходят.
Вот оно как бы просто в теории, а на практике обнаружится, что админке нужно делать какие-то свои выборки, а лк клиента - свои. И в application/persistence начнут появляться методы для этих выборок. А потом, спустя N месяцев уже непонятно будет, зачем существуют те или иные методы. В репозиториях будет по 10 тысяч строк. И тогда начнёшь думать, что может и лучше чтобы админка и лк клиента сами ходили в персистенцию - так хоть понятно было бы, какой код за какой кусок логики отвечает.
Так что ответ зависит от размера приложения. Можно и так и эдак. Первичны всегда данные - если их нельзя логически разделить на две разных базы - у вас одно приложение, а не два.
Например, в интернет-магазине есть личный кабинет клиента и админка менеджера по отправке. UI разные, но они оба делают выборку по заказам клиентов.
Как это может выглядеть в зонтичном проекте (по трёхтировой схеме):
apps
customer_ui
admin_ui
application
persistence
application содержит контроль инвариантов согласно бизнес-правилам
persistence - низкоуровневый инфраструктурный слой, экто там или что-то ещё
customer_ui и admin ходят в application за чтобы сделать write или read, в persistence напрямую не ходят.
Вот оно как бы просто в теории, а на практике обнаружится, что админке нужно делать какие-то свои выборки, а лк клиента - свои. И в application/persistence начнут появляться методы для этих выборок. А потом, спустя N месяцев уже непонятно будет, зачем существуют те или иные методы. В репозиториях будет по 10 тысяч строк. И тогда начнёшь думать, что может и лучше чтобы админка и лк клиента сами ходили в персистенцию - так хоть понятно было бы, какой код за какой кусок логики отвечает.
Так что ответ зависит от размера приложения. Можно и так и эдак. Первичны всегда данные - если их нельзя логически разделить на две разных базы - у вас одно приложение, а не два.
Хороший ответ, от себя добавлю что помимо горизонтального разделения архитектуры по слоям, есть ещё и вертикальное по контекстам/доменам в котором тоже придётся искать место для базы
Вариантов-то всего четыре:
1. База и интерфейс к ней у каждого сервиса/контекста/приложения разные
2. База общая, но интерфейсы разные
3. Базы разные, интерфейс один
4. База общая и интерфейс общий
Под базой я имею в виду именно инстанс базы, а под интерфейсом имею в виду схемки, миграции и всё такое. Я почти с каждым из этих случаев так или иначе сталкивался на работе и везде есть плюсы и минусы
В первом варианте, всё очень безопасно, сервисы/контексты не зависят друг от друга, но будут проблемы с консистентностью для межконтекстных запросов
Во втором варианте, проблем с консистентностью для межконтекстных запросов не будет, но будут проблемы с
В третьем варианте будут жуткие проблемы с миграциями, каждый сервис будет невольно знать о куче ненужных сущностей. Тоже духота
В четвертом варианте не будет проблем с консистентносью, миграциями и всем таким, но интерфейс очень быстро разжиреет и на базу будет очень сильная нагрузка
Так что в итоге, четвёртый вариант идеален для маленьких проектов и нагрузок, первый вариант хорош для больших проектов с сильной архитектурой, а второй и третий какие-то уж сильно экзотические и тут нужно понимать что они ведут к сильной связности контекстов, что не всегда хочется иметь в своих проектах
Вариантов-то всего четыре:
1. База и интерфейс к ней у каждого сервиса/контекста/приложения разные
2. База общая, но интерфейсы разные
3. Базы разные, интерфейс один
4. База общая и интерфейс общий
Под базой я имею в виду именно инстанс базы, а под интерфейсом имею в виду схемки, миграции и всё такое. Я почти с каждым из этих случаев так или иначе сталкивался на работе и везде есть плюсы и минусы
В первом варианте, всё очень безопасно, сервисы/контексты не зависят друг от друга, но будут проблемы с консистентностью для межконтекстных запросов
Во втором варианте, проблем с консистентностью для межконтекстных запросов не будет, но будут проблемы с
data race-ами на foreign key, миграциями. Душный вариант, я бы такой не рекомендовалВ третьем варианте будут жуткие проблемы с миграциями, каждый сервис будет невольно знать о куче ненужных сущностей. Тоже духота
В четвертом варианте не будет проблем с консистентносью, миграциями и всем таким, но интерфейс очень быстро разжиреет и на базу будет очень сильная нагрузка
Так что в итоге, четвёртый вариант идеален для маленьких проектов и нагрузок, первый вариант хорош для больших проектов с сильной архитектурой, а второй и третий какие-то уж сильно экзотические и тут нужно понимать что они ведут к сильной связности контекстов, что не всегда хочется иметь в своих проектах
2020 November 22
2020 November 23
Е
Скажите, пожалуйста, а
Phoenix.PubSub гарантирует соблюдение очередности сообщений? То бишь, если был сделан broadcast сообщения A, а затем B, то никакой подписчик не получит B раньше A.Е
А нужно это вот для чего. Я бы хотел расшарить некий большой объект между несколькими нодами. Но объект часто меняется и чтобы не передавать этот объект целиком, возникла мысль передавать только его изменения с указанием версии.
Я хочу чего-то странного? Или может есть уже готовые велосипеды для подобного?
Я хочу чего-то странного? Или может есть уже готовые велосипеды для подобного?
LL
Скажите, пожалуйста, а
Phoenix.PubSub гарантирует соблюдение очередности сообщений? То бишь, если был сделан broadcast сообщения A, а затем B, то никакой подписчик не получит B раньше A.Если
pubsub поверх pg, то должен быть порядок, но гарантии всё равно нетЕ
Владелец и "изменятель" у объекта только один, а "чтецов" много.