Comments 11
Правило Go никогда не упоминать о Бойцовском клубе не использовать фреймворки. Если не секрет, на чем писали до Go?
Разрешите поинтересоваться в причинах данной практики?
Ps. сам в го не разбираюсь, спрашиваю для общего развития
Возможно выше просто шутка. В го хорошая стандартная бибилиотека, поэтому для ряда задач(особенно если проект небольшой) можно обойтись без фреймворков. Могу сказать только, что достаточно много людей плохо относится к ORM, наиболее популярная реализация это gORM, но её не любят использовать из-за того, что она использует reflect, что дает оверхед.
Добавление слишком большой сложности ради небольшой экономии времени.
Обычно используют инструменты, решающие конкретные задачи, а не комплексные фреймворк.
Для проблем, которые автор статьи описывает, фреймворками или библиотеками пользоваться не принято.
injector.Bind - прям Guice веет из Java
Иначе это будет Go++, а этого допустить никак нельзя.
В Go ценят простоту и прозрачность, которые первыми проносятся в жертву при использовании фреймворков. Для того, чтобы понять, как работает приложение, написанное с использованием фреймворка, нужно сначала понять, как устроен фреймворк, и какие неявные конвенции он использует. Код приложения становится несамодостаточным, его нельзя понять, не изучив предварительно фреймворк. В Go так стараются не делать. С библиотеками проблем в этом смысле меньше, так как они более узкосфокусированы, и не диктуют пользователям, как они должны разрабатывать приложение
Не имею много опыта ни как в реализации DDD, ни даже в самом Go, но все же осмелюсь выразить свои сомнения. Заключаются они в том, что читая документацию Go я не нашел и намека на подобную архитектуру. Напротив в ней советуются не перенимать идиомы других языков, а попытаться осмыслить его собственные:
A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go. On the other hand, thinking about the problem from a Go perspective could produce a successful but quite different program. In other words, to write Go well, it's important to understand its properties and idioms.
Чуть дальше сказано, что можно руководствоваться исходным кодом Go (который на данный момент уже написан на самом себе) как примером правильного использования языка:
The Go package sources are intended to serve not only as the core library but also as examples of how to use the language.
В исходом коде - опять же не используется ddd (хотя кодовая база не маленькая - 70 тыщ строк где-то). Если приглядеться - в нем не найти общих названий папок, например: domain, controllers, handlers, - объединяющих несколько сущностей по признаку контекста использования. Также там не используется DI контейнеры - все построено на интерфейсах (причем интерфейсы объявлены на принимающей стороне, а не на реализующей). И в целом архитектура примитивна в хорошем смысле. Тем не менее, судя по слухам, кодовая база Go очень гибко построена, язык кажется не встречает архитектурных препятствий в дальнейшем развитии. Мне кажется такой минимализм - часть философии Go, и отказ от излишних наворотов в виде фрэймворка, di контейнеров, orm, ddd и так далее, в пользу принятия "go way" может оказать большую эффективность на процесс разработки.
Я не утверждаю, что прав. Возможно и вероятно, мое мнение ограничено недостатком опыта и в более энтерпрайзных проектах такой подход - выигрышный. Хотелось бы услышать тех, кто применял и данную архитектуру и "go way". Какой подход более эффективен и в каких случая? Заранее спасибо :)
да, не совсем понятно для чего автор(ы) взяли Go, ведь он родился out of frustration with existing languages. Можно было взять ту же джаву либо гопнет, и там наворачивать все эти DI и спринг буты. там это гораздо лучше развито.
То, что представленный подход - это анти-go согласен, но не из-за DDD. DDD не используют для разработки компиляторов, или библиотек, оно нужно для микросервисов и с go прекрасно сочетается. DDD не имеет никакого отношения ни к DI, ни к событиям ни к ORM, ни к какой-то структуре папок. DDD - это про то, как разделять ответственность между (микро)сервисами, модулями и пр. Без DDD микросервисы практически всегда вырождаются в распределенный монолит и если мы пишем микросервисы на go, то без DDD не обойтись. Но это не значит, что надо тащить DI, ORM и прочее из Java мира. В Go лучше без этого
Flamingo, Go ahead! или Как реализовать DDD в Go?