Pull to refresh

Comments 11

прекрасно. Много че нового и полезного
Если это интернет-магазин и СУБД, то нет никакой гарантии что сумма заказа не превысит $250. Так что домен в том числе зависит от приложения. То что красиво работает в однопользовательской консольке вовсе не работает в многосерверных сайтах.
Это же статья не про бизнес всё таки, а про архитектуру приложения.
Если честно, не вижу связи между магазином, СУБД и превышением 250$
простой пример а не готовый код в продакшин
Это крутая статья, читал в оригинале, но вот интересно было бы пообщаться с теми, кто этот подход к архитектуре реально на практике использует.
О! Помню эту статью, я автору огромный комментарий написал от всей души, а он мне ответил на него через несколько месяцев одной строчкой, которая противоречит его же постулатам из статьи. Если кто-нибудь категорически разделяет и понимает позицию автора, буду благодарен ответу на свои вопросы из оригинального комментария. Его легко найти внизу от оригинальной статьи, способа сделать ссылку на комментарий к сожалению не нашёл.
> способа сделать ссылку на комментарий к сожалению не нашёл.
Вот так, если я правильно нашёл комментарий.
UFO just landed and posted this here
Жаль, что это переводная статья. Я бы хотел немного подискутировать именно с автором статьи, а не перевода. Возможно, кто-то захочет ответить?

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

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

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


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


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


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

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

Articles