/
уже не хочу.
Size: a a a
2020 June 06
/
ok
Н
Вот у вас
notesStorage более менее пример нормального интерфейса. Он оперирует бизнес моделями и отвязан от какой либо реализации. Т.е. по нему невозможо сказать что за база под этим интерфейсом лежит. SQL там или HTTP сервис... Что хотите то и подставляйте. Сегодня мнонлит и пишем в одну базу, завтра решили кусок унести в отдельный сервис, сели, написали новую реализацию для notesStorage, теперь она работает по HTTP. Остальной код при этом не изменитсяДа, я понимаю смысл этого подхода – отдельные структуры под отдельные сущности: если вдруг поменяется реализация обработки данных конкретно этой сущности. Если же она не меняется, и у нас одна БД?
AK
Да, я понимаю смысл этого подхода – отдельные структуры под отдельные сущности: если вдруг поменяется реализация обработки данных конкретно этой сущности. Если же она не меняется, и у нас одна БД?
Если у вас одна БД, если вы уверены что она не изменится, вы можете вообще не использовать DIP и просто вызывать методы БД напрямую без каких либо интерфейсов и абстракций
Н
Если у вас одна БД, если вы уверены что она не изменится, вы можете вообще не использовать DIP и просто вызывать методы БД напрямую без каких либо интерфейсов и абстракций
Уверенность только в том, что не будет разбивка под каждую сущность. А так БД может поменяться
DP
Да, я понимаю смысл этого подхода – отдельные структуры под отдельные сущности: если вдруг поменяется реализация обработки данных конкретно этой сущности. Если же она не меняется, и у нас одна БД?
ну - н разу я такого не видал
Н
ну - н разу я такого не видал
Что одна БД?
AK
Мне кажется проще всего объяснить, как бы сделал кто-то из нас, это взять ваш проект, форкнуть и отрефакторить, тем самым показав как можно по другому.
DP
Что одна БД?
в современном мире - и это редкость
потому, что реляционка-транзакционка нужна палюбэ, и данные, под которую нужна кластерная, есть теперь в половине проектов
потому, что реляционка-транзакционка нужна палюбэ, и данные, под которую нужна кластерная, есть теперь в половине проектов
Н
в современном мире - и это редкость
потому, что реляционка-транзакционка нужна палюбэ, и данные, под которую нужна кластерная, есть теперь в половине проектов
потому, что реляционка-транзакционка нужна палюбэ, и данные, под которую нужна кластерная, есть теперь в половине проектов
Это на каком масштабе?
DP
Это на каком масштабе?
от данных зависит
Н
Вот, например, https://github.com/bxcodec/go-clean-arch. Это хороший пример? @antonikucherov
AK
Вот, например, https://github.com/bxcodec/go-clean-arch. Это хороший пример? @antonikucherov
Как и многие примеры высосан из пальца и реализован нарачито явно. Хотя принципы показывает неплохо, да. Но опять таки, не фокусируйтесь на пакетах и каталогах, сфокусируйтесь на абстракциях и том, что от чего зависит и кто кого реализует и использует. Как я раньше говорил, Clean в частности и разделение на слои в целом можно реализовать вообще не имея пакетов и не разбивая код на каталоги.
ЛА
Классические примеры хороших названий интерфейсов reader/writer/closer
Да, примеры есть, но имхо суффикс -er не всегда однозначно говорит, что это интерфейс.
Непонятно, почему не добавить суффикс interface, чтобы все было очевидно
Непонятно, почему не добавить суффикс interface, чтобы все было очевидно
AK
Суффикс
-er образует существительное из глагола. 🙂 При чем не во всех случаях. Read - читать, Reader - читатель. Write - писать, Writer - писатель. Storage - хранилище, Storager - бессмыслица. 🙂Н
Как и многие примеры высосан из пальца и реализован нарачито явно. Хотя принципы показывает неплохо, да. Но опять таки, не фокусируйтесь на пакетах и каталогах, сфокусируйтесь на абстракциях и том, что от чего зависит и кто кого реализует и использует. Как я раньше говорил, Clean в частности и разделение на слои в целом можно реализовать вообще не имея пакетов и не разбивая код на каталоги.
Вроде как понимаю, о чем вы, но в то же время не до конца. Хорошо, от чего вообще надо отталкиваться? От юзкейса и его потребностей?
AK
Вроде как понимаю, о чем вы, но в то же время не до конца. Хорошо, от чего вообще надо отталкиваться? От юзкейса и его потребностей?
Типа того, да. От юзкейса или от набора юзкейсов. В общем от потребностей именно той задачи которую вы решаете. Т.е. API интерфейсов диктуется высокоуровневым кодом а не низкоуровневым.
zl
> Руки не доходят до книг по DDD. Как-то, и надобности не ощущается.
Ну и хорошо. Значит нет тех проблем которые этот подход помогает решить. Я вот точно так же не понимаю людей которые постоянно считают аллокации и заморочены на повсеместной оптимизации. И знаете почему? Все просто, я с проблемами оптимизации практически никогда не сталкивался в личном опыте, и это нормально. Столкнусь и сразу руки дойдут.
Ну и хорошо. Значит нет тех проблем которые этот подход помогает решить. Я вот точно так же не понимаю людей которые постоянно считают аллокации и заморочены на повсеместной оптимизации. И знаете почему? Все просто, я с проблемами оптимизации практически никогда не сталкивался в личном опыте, и это нормально. Столкнусь и сразу руки дойдут.
Столкнусь и сразу руки дойдут.
руки могут не успеть дойти - вжжух и уже голодранец
это хорошо, когда полет фантазии оплачивает заказчик, а когда со своего кармана, то все выглядит уже совсем не так радужно
руки могут не успеть дойти - вжжух и уже голодранец
это хорошо, когда полет фантазии оплачивает заказчик, а когда со своего кармана, то все выглядит уже совсем не так радужно