/
Size: a a a
2020 June 06
/
Как-бы помягче сказать... Попробуйте другой архитектурный подход.
AK
Руки не доходят до книг по DDD. Как-то, и надобности не ощущается пока что. Я вообще себе накидал шаблон приложения, по которому что-то делаю изначально. https://github.com/floyernick/Init. Если у вас будет возможность просмотреть и дать небольшое ревью, будет интересно
Ваш подход похож на классический
Ruby On Rails подход. Т.е. приложение поделено на пакеты по слоям. Тот же Мартин, говорит о том, что код нужно делить по зонам ответсвенности а не по слоям. Слои можно реализовать даже в рамках одного пакета. Для этого достаточно соблюдать правило зависимостей. Проще говоря, деление на каталоги - не настолько принципиально важно, как выбор правильных абстракций и следование принципа инверсии зависимостей (между слоями)./
Вообще ИМХО стоит почитать труд дяди Боба, но не нужно следовать карго культу.
Н
Ваш подход похож на классический
Ruby On Rails подход. Т.е. приложение поделено на пакеты по слоям. Тот же Мартин, говорит о том, что код нужно делить по зонам ответсвенности а не по слоям. Слои можно реализовать даже в рамках одного пакета. Для этого достаточно соблюдать правило зависимостей. Проще говоря, деление на каталоги - не настолько принципиально важно, как выбор правильных абстракций и следование принципа инверсии зависимостей (между слоями).Да, только я не совсем понимаю профита от деления по зонам ответственности. С точки зрения продукта, что ли, нагляднее будет делить по зонам, понимать что есть в продукте со стороны бизнеса.
Но в техническом плане, профит в чем будет? И разве это не приведет к дублированию реализации сервисов в каждый пакет? Например, дублировать имплементацию БД, очереди, прочего
Но в техническом плане, профит в чем будет? И разве это не приведет к дублированию реализации сервисов в каждый пакет? Например, дублировать имплементацию БД, очереди, прочего
AK
/dev/null
Вы смотрели этот репо?
Так там не реализовано то о чем дядя Боб говорит. То о чем он говорит, к примеру реализовано в функции
io.Copy (и в пакете io в целом) в стандартной библиотеке Go к примеру./
Так там не реализовано то о чем дядя Боб говорит. То о чем он говорит, к примеру реализовано в функции
io.Copy (и в пакете io в целом) в стандартной библиотеке Go к примеру.эм... так я совсем не это имел ввиду, я написал что так делать не нужно. вообще по этому проекту не понятно что автор пытался туда принести.
AK
/dev/null
эм... так я совсем не это имел ввиду, я написал что так делать не нужно. вообще по этому проекту не понятно что автор пытался туда принести.
Я думаю автор практикуется и это хорошо. А так же я думаю автор хочет послушать конкретные проблемы его имплементации, чтобы в будущем стать лучше. На мой взгляд так делать нужно, потому что на ошибках учатся
/
Я думаю автор практикуется и это хорошо. А так же я думаю автор хочет послушать конкретные проблемы его имплементации, чтобы в будущем стать лучше. На мой взгляд так делать нужно, потому что на ошибках учатся
Да я согласен с вами.
/
Будет хорошо если их адресуете
Посмотрите сюда.
https://github.com/golang-standards/project-layout
Это не священный Грааль но стоит посмотреть на этот подход.
https://github.com/golang-standards/project-layout
Это не священный Грааль но стоит посмотреть на этот подход.
p
> Руки не доходят до книг по DDD. Как-то, и надобности не ощущается.
Ну и хорошо. Значит нет тех проблем которые этот подход помогает решить. Я вот точно так же не понимаю людей которые постоянно считают аллокации и заморочены на повсеместной оптимизации. И знаете почему? Все просто, я с проблемами оптимизации практически никогда не сталкивался в личном опыте, и это нормально. Столкнусь и сразу руки дойдут.
Ну и хорошо. Значит нет тех проблем которые этот подход помогает решить. Я вот точно так же не понимаю людей которые постоянно считают аллокации и заморочены на повсеместной оптимизации. И знаете почему? Все просто, я с проблемами оптимизации практически никогда не сталкивался в личном опыте, и это нормально. Столкнусь и сразу руки дойдут.
Можно очень неожиданно столкнуться с ними :) причем, даже не по cpu :)
/
Надеюсь не начнется холивар)
AK
/dev/null
Да я согласен с вами.
Ну и да, я не отрицаю, что возможно того же Мартина, нужно читать имея за плечами определенный опыт, и что вполне возможно то о чем он пишет может повредить при отсутствии опыта.