Чистая архитектура в Go-приложении. Часть 1

[KvanTTT]

Прямо неделя Го наступила.

[sergeylanz]

прекрасно. Много че нового и полезного

[gandjustas]

Если это интернет-магазин и СУБД, то нет никакой гарантии что сумма заказа не превысит $250. Так что домен в том числе зависит от приложения. То что красиво работает в однопользовательской консольке вовсе не работает в многосерверных сайтах.

[EgorLyutov]

Это же статья не про бизнес всё таки, а про архитектуру приложения.

[trong]

Если честно, не вижу связи между магазином, СУБД и превышением 250$

[sergeylanz]

простой пример а не готовый код в продакшин

[divan0]

Это крутая статья, читал в оригинале, но вот интересно было бы пообщаться с теми, кто этот подход к архитектуре реально на практике использует.

[Kluyg]

О! Помню эту статью, я автору огромный комментарий написал от всей души, а он мне ответил на него через несколько месяцев одной строчкой, которая противоречит его же постулатам из статьи. Если кто-нибудь категорически разделяет и понимает позицию автора, буду благодарен ответу на свои вопросы из оригинального комментария. Его легко найти внизу от оригинальной статьи, способа сделать ссылку на комментарий к сожалению не нашёл.

[rokorok]

> способа сделать ссылку на комментарий к сожалению не нашёл.
Вот так, если я правильно нашёл комментарий.

[questor]

Жаль, что это переводная статья. Я бы хотел немного подискутировать именно с автором статьи, а не перевода. Возможно, кто-то захочет ответить?

Вот автор пишет так ненавязчиво:

Системы, состоящие из частей поддающихся тестированию и слабосвязанных между собой компонент могут расширяться без особых проблем, прозрачны для понимания, модификации, расширения и масштабирования.

Круто — то, что нужно.

И тут же оказывается, что все эти слабозавязанные компоненты — хрен переделаешь, малой кровью не обойтись:

Это достаточно тонкое различие, поскольку когда ваша программа мала, то решение, что пользователи и клиенты — это одно и то же, не кажется большим делом. Но это одна из тех вещей, которые в последствии будет сложно исправить.

И главное в каком месте, а? Читаем дальше:

Но это одна из тех вещей, которые в последствии будет сложно исправить. Причина в том, что для 99% ситуаций допущение, что пользователи и клиенты — это одно и то же ровно ничего не значит, до тех пор пока не вступает в игру оставшийся 1%.

Оказывается, вся эта архитектура была сделана для одного: чтобы можно было абстрагироваться от базы:

В то же время это лакмусовая бумажка для наших внутренних слоев — должны ли мы изменить хоть одну строчку кода при переключении с MySQL на Oracle?

Так вот… Честно говоря, мне редко встречалось в практике менять тип базы с одного на другой. А вот смена бизнес-требований — это постоянная работа. Когда приходит бизнес и говорит «а вот раньше у нас был такой тип клиентов, а мы сейчас взяли заказ ещё у того-то». И по факту приходится заниматься именно подгонкой приложения на разных слоях, а не менять базу. И предугадать, где завтра бизнес принесёт деньги — просто тухлый номер. А у него прям так всё красиво: мы на старте уже знаем все архитектурные допущения. Лол.

Толи автор сам не понимает того, что пытается сделать, толи продаёт правильные идеи неправильно их аргументируя.