Комментарии 11
Прямо неделя Го наступила.
Если это интернет-магазин и СУБД, то нет никакой гарантии что сумма заказа не превысит $250. Так что домен в том числе зависит от приложения. То что красиво работает в однопользовательской консольке вовсе не работает в многосерверных сайтах.
Это крутая статья, читал в оригинале, но вот интересно было бы пообщаться с теми, кто этот подход к архитектуре реально на практике использует.
О! Помню эту статью, я автору огромный комментарий написал от всей души, а он мне ответил на него через несколько месяцев одной строчкой, которая противоречит его же постулатам из статьи. Если кто-нибудь категорически разделяет и понимает позицию автора, буду благодарен ответу на свои вопросы из оригинального комментария. Его легко найти внизу от оригинальной статьи, способа сделать ссылку на комментарий к сожалению не нашёл.
> способа сделать ссылку на комментарий к сожалению не нашёл.
Вот так, если я правильно нашёл комментарий.
Вот так, если я правильно нашёл комментарий.
НЛО прилетело и опубликовало эту надпись здесь
Жаль, что это переводная статья. Я бы хотел немного подискутировать именно с автором статьи, а не перевода. Возможно, кто-то захочет ответить?
Вот автор пишет так ненавязчиво:
Круто — то, что нужно.
И тут же оказывается, что все эти слабозавязанные компоненты — хрен переделаешь, малой кровью не обойтись:
И главное в каком месте, а? Читаем дальше:
Оказывается, вся эта архитектура была сделана для одного: чтобы можно было абстрагироваться от базы:
Так вот… Честно говоря, мне редко встречалось в практике менять тип базы с одного на другой. А вот смена бизнес-требований — это постоянная работа. Когда приходит бизнес и говорит «а вот раньше у нас был такой тип клиентов, а мы сейчас взяли заказ ещё у того-то». И по факту приходится заниматься именно подгонкой приложения на разных слоях, а не менять базу. И предугадать, где завтра бизнес принесёт деньги — просто тухлый номер. А у него прям так всё красиво: мы на старте уже знаем все архитектурные допущения. Лол.
Толи автор сам не понимает того, что пытается сделать, толи продаёт правильные идеи неправильно их аргументируя.
Вот автор пишет так ненавязчиво:
Системы, состоящие из частей поддающихся тестированию и слабосвязанных между собой компонент могут расширяться без особых проблем, прозрачны для понимания, модификации, расширения и масштабирования.
Круто — то, что нужно.
И тут же оказывается, что все эти слабозавязанные компоненты — хрен переделаешь, малой кровью не обойтись:
Это достаточно тонкое различие, поскольку когда ваша программа мала, то решение, что пользователи и клиенты — это одно и то же, не кажется большим делом. Но это одна из тех вещей, которые в последствии будет сложно исправить.
И главное в каком месте, а? Читаем дальше:
Но это одна из тех вещей, которые в последствии будет сложно исправить. Причина в том, что для 99% ситуаций допущение, что пользователи и клиенты — это одно и то же ровно ничего не значит, до тех пор пока не вступает в игру оставшийся 1%.
Оказывается, вся эта архитектура была сделана для одного: чтобы можно было абстрагироваться от базы:
В то же время это лакмусовая бумажка для наших внутренних слоев — должны ли мы изменить хоть одну строчку кода при переключении с MySQL на Oracle?
Так вот… Честно говоря, мне редко встречалось в практике менять тип базы с одного на другой. А вот смена бизнес-требований — это постоянная работа. Когда приходит бизнес и говорит «а вот раньше у нас был такой тип клиентов, а мы сейчас взяли заказ ещё у того-то». И по факту приходится заниматься именно подгонкой приложения на разных слоях, а не менять базу. И предугадать, где завтра бизнес принесёт деньги — просто тухлый номер. А у него прям так всё красиво: мы на старте уже знаем все архитектурные допущения. Лол.
Толи автор сам не понимает того, что пытается сделать, толи продаёт правильные идеи неправильно их аргументируя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чистая архитектура в Go-приложении. Часть 1