Это проходит по категории «тривиальный». Чтобы он стал не-тривиальным, нужно иметь критерии, отличающие «хорошую» абстракцию от «плохой».
Был бы рад, если бы вы скинули литературы, которая учит отличать хорошую от плохой.
А код-то как писать, если не принимать такие архитектурные решения рано?
Ну в моем понимании, ваше приложение должно иметь какую-то свою логику (бизнес логику), и начать нужно именно с ней, а не имплементить доступ к данным сходу — вот о чем говорит автор.
Кроме того, книга эта я бы не сказал что для опытных ребят, это скорее для новичков вроде меня, где разложенные и разжеванные основы
Я думаю, здесь многое зависит от самого проекта, естественно переход к новому способу хранения данных — это всегда боль, вопрос будет в том насколько это будет больно. Как минимум совет инкапсулировать доступ к данным через какую-нибудь абстракцию — рабочий, и малость снизит боль перехода. + к этом будет простота в тестировании. А общего и безболезненного солюшна нету, я думаю. Поэтому и в конце автор говорит, и в книге есть его личные примере с его опыта, что такого рода архитектурные решения нужно принимать как можно позже — что бы свести к минимуму вероятность изменения способа хранения данных
Полностью согласен с вами, не всегда можно просто сменить способ хранение данных. Имеется в виду скорее переход с однотипных баз данных, например c Postgresql на MSSQL и т.д.
Даже в случае key-value, я думаю, это нужно инкапсулировать доступ к данным так или иначе.
Был бы рад, если бы вы скинули литературы, которая учит отличать хорошую от плохой.
Ну в моем понимании, ваше приложение должно иметь какую-то свою логику (бизнес логику), и начать нужно именно с ней, а не имплементить доступ к данным сходу — вот о чем говорит автор.
Кроме того, книга эта я бы не сказал что для опытных ребят, это скорее для новичков вроде меня, где разложенные и разжеванные основы
Даже в случае key-value, я думаю, это нужно инкапсулировать доступ к данным так или иначе.