OS
dependancy они неизбежны, в них суть предметной области
Size: a a a
2019 March 26
SS
Ну я о том же, если их нет то и вопросов и ответов нет
OS
а вот чтобы их не пере-coupl-ить сверх необходимого - как раз навыдумывали всяких абстракций
SS
«Квадрат это не прямоугольник» :)
OS
кстати, забыл про event sourcing, это, пожалуй, не частный случай сообщений
OS
и возможно единственный случай, когда что-то типа "медиатора" и баз могут вроде как и не увеличивать coupling, но это не точно :)
OS
или не так, скорее, если у вас иммутабельные данные а ещё лучше и иммутабельный код тоже, то побочные эффекты от каплинга вас сильно меньше беспокоят...
или даже так: пока вы поймёте как сделать всё иммутабельным, вы и так хорошую архитектуру вынуждены будете родить 🙂
или даже так: пока вы поймёте как сделать всё иммутабельным, вы и так хорошую архитектуру вынуждены будете родить 🙂
P
Такой чувак интересный про девопс рассказывал. Супер
OS
Ведущим удаётся правильных экспертов находить, из того что я слышал. Тех, кто не только в теме, но и умеет голосом 🙂
SS
или не так, скорее, если у вас иммутабельные данные а ещё лучше и иммутабельный код тоже, то побочные эффекты от каплинга вас сильно меньше беспокоят...
или даже так: пока вы поймёте как сделать всё иммутабельным, вы и так хорошую архитектуру вынуждены будете родить 🙂
или даже так: пока вы поймёте как сделать всё иммутабельным, вы и так хорошую архитектуру вынуждены будете родить 🙂
Ну касательно приложений, все равно изменчивость где то да будет....проводить ее через слой БД, делая неизменные экраны, или изменять на экране отправляя изменения в БД....вероятно тут будет скорость vs багоустойчивость
ET
Ведущим удаётся правильных экспертов находить, из того что я слышал. Тех, кто не только в теме, но и умеет голосом 🙂
❤️
OS
Ну касательно приложений, все равно изменчивость где то да будет....проводить ее через слой БД, делая неизменные экраны, или изменять на экране отправляя изменения в БД....вероятно тут будет скорость vs багоустойчивость
сорян, я в гуях и фронтенде в-целом - лох... даже не знаю, есть ли у вас способ что-то "изменять на экране" просто "отправляя изменения в базу", кроме как тупой поллинг.
OS
но я про иммутабельность совсем в других местах имел в виду
OS
если у тебя event sourcing, то в теории ты можешь в БД сложить ивенты, и они будут иммутабельны...
а для вычисления стейта у тебя вынуждено будет обзёрвер, но не какой-то хрен пойми сбоку, как в задаче про два стула выше, а родной, понятный и потому тоже редко изменяемый
а для вычисления стейта у тебя вынуждено будет обзёрвер, но не какой-то хрен пойми сбоку, как в задаче про два стула выше, а родной, понятный и потому тоже редко изменяемый
SS
сорян, я в гуях и фронтенде в-целом - лох... даже не знаю, есть ли у вас способ что-то "изменять на экране" просто "отправляя изменения в базу", кроме как тупой поллинг.
Сделать чтобы «экран» «следил» за базой, точнее за «контекстом в котором объекты»
SS
если у тебя event sourcing, то в теории ты можешь в БД сложить ивенты, и они будут иммутабельны...
а для вычисления стейта у тебя вынуждено будет обзёрвер, но не какой-то хрен пойми сбоку, как в задаче про два стула выше, а родной, понятный и потому тоже редко изменяемый
а для вычисления стейта у тебя вынуждено будет обзёрвер, но не какой-то хрен пойми сбоку, как в задаче про два стула выше, а родной, понятный и потому тоже редко изменяемый
есть как бы не «стейт» а набор «операций» из которых он вычисляется?....такого в приложениях не помню
SS
Вроде законы физики не запрещают такое реализовать....но ведь медленно будет, каждый раз вычислять....а если «кэш» хранить то кэш будет мутабельным
SS
Плюс - что будет если отменить операцию посередине....а если только инкремент операций то размер будет в какой то момент большим
SS
Это все мои измышления не претендующие на истину :)