Не имею много опыта ни как в реализации 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". Какой подход более эффективен и в каких случая? Заранее спасибо :)
Рофл нот детектед)
Не имею много опыта ни как в реализации DDD, ни даже в самом Go, но все же осмелюсь выразить свои сомнения. Заключаются они в том, что читая документацию Go я не нашел и намека на подобную архитектуру. Напротив в ней советуются не перенимать идиомы других языков, а попытаться осмыслить его собственные:
Чуть дальше сказано, что можно руководствоваться исходным кодом Go (который на данный момент уже написан на самом себе) как примером правильного использования языка:
В исходом коде - опять же не используется ddd (хотя кодовая база не маленькая - 70 тыщ строк где-то). Если приглядеться - в нем не найти общих названий папок, например: domain, controllers, handlers, - объединяющих несколько сущностей по признаку контекста использования. Также там не используется DI контейнеры - все построено на интерфейсах (причем интерфейсы объявлены на принимающей стороне, а не на реализующей). И в целом архитектура примитивна в хорошем смысле. Тем не менее, судя по слухам, кодовая база Go очень гибко построена, язык кажется не встречает архитектурных препятствий в дальнейшем развитии. Мне кажется такой минимализм - часть философии Go, и отказ от излишних наворотов в виде фрэймворка, di контейнеров, orm, ddd и так далее, в пользу принятия "go way" может оказать большую эффективность на процесс разработки.
Я не утверждаю, что прав. Возможно и вероятно, мое мнение ограничено недостатком опыта и в более энтерпрайзных проектах такой подход - выигрышный. Хотелось бы услышать тех, кто применял и данную архитектуру и "go way". Какой подход более эффективен и в каких случая? Заранее спасибо :)