Пятничное чтиво
На следующей неделе стрим, попробуем сделать raft consensus алгоритм на руби. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Vertical Slice Architecture
Out with the Onion, in with Vertical Slices
На последнем стриме показывал концепцию слайсов в hanami 2.0. Идея в том, что горизонтальные части приложения (ui, application, domain, db) разбить не только горизонтально, но и вертикально. Это значит, что в самом приложении появляются “слайсы”, в которых находятся логика изолированно друг от друга. В комментариях к статье дается группа сервисов как пример для понимания. Кажется, что аналогия rails engines подходит для быстрого объяснения подхода, тем более об этом уже начинают говорить (за подробностями - к автору доклада, @greygreen).
В первой статье с картинками объясняется как паттерн работает подробнее. Во второй больше уделяется вниманиям плюсам и минусам подхода, а также дается пример, показывающий, что слайсы могут быть использованы не только в бэкенде.
Если хотите понять подготовиться к hanami 2.0 или же хотите взять идей для rails engines - мастхев.
—————————————
[Clean Architecture: The Bad Parts](http://amp.gs/Hhg4)
На прошлой неделе в рассылке присутствовали статьи автора касаемые aggregates из DDD. Сегодня статья о проблемах “clean architecture”. В начале описывается что это такое (спойлер: порты и адаптеры). Потом описываются принципы, которые должны в такой системе соблюдаться. Но к сожалению, реальность иначе. Поэтому автор описывает проблемы, с которыми встретился лично (Context Switching). Так же ставится риторический вопрос о действительной необходимости изменения базы данных в приложениях. В качестве “серебрянкой пули” предлагается использование слайсов, о которых рассказывала первая статья.
Кажется, что тема слайсов будет развиваться дальше по трем причинам (время для #2pe\analytics):
1. кажется, что микросервисы дошли до Trough of Disillusionment и разговоров о возврате к монолитам становится больше в моем пузыре;
2. ограничивать части монолита нужно, DDD добавляет абстракций, использовать сервисы, декораторы и другие объекты в больших проектах сложно (куча хлама в одном месте). По идее, слайсы как раз и могут решить проблему поддерживаемости, при этом не добавляя проблем распределенных систем;
3. об этом начинают говорить не только в .net но и в js, ruby и других экосистемах.
При этом, я думаю, что подход вряд-ли окажется популярным как микросервисы, но он доступен для любой
экосистемы, даже для rails.
На следующей неделе стрим, попробуем сделать raft consensus алгоритм на руби. Старые записи можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Vertical Slice Architecture
Out with the Onion, in with Vertical Slices
На последнем стриме показывал концепцию слайсов в hanami 2.0. Идея в том, что горизонтальные части приложения (ui, application, domain, db) разбить не только горизонтально, но и вертикально. Это значит, что в самом приложении появляются “слайсы”, в которых находятся логика изолированно друг от друга. В комментариях к статье дается группа сервисов как пример для понимания. Кажется, что аналогия rails engines подходит для быстрого объяснения подхода, тем более об этом уже начинают говорить (за подробностями - к автору доклада, @greygreen).
В первой статье с картинками объясняется как паттерн работает подробнее. Во второй больше уделяется вниманиям плюсам и минусам подхода, а также дается пример, показывающий, что слайсы могут быть использованы не только в бэкенде.
Если хотите понять подготовиться к hanami 2.0 или же хотите взять идей для rails engines - мастхев.
—————————————
[Clean Architecture: The Bad Parts](http://amp.gs/Hhg4)
На прошлой неделе в рассылке присутствовали статьи автора касаемые aggregates из DDD. Сегодня статья о проблемах “clean architecture”. В начале описывается что это такое (спойлер: порты и адаптеры). Потом описываются принципы, которые должны в такой системе соблюдаться. Но к сожалению, реальность иначе. Поэтому автор описывает проблемы, с которыми встретился лично (Context Switching). Так же ставится риторический вопрос о действительной необходимости изменения базы данных в приложениях. В качестве “серебрянкой пули” предлагается использование слайсов, о которых рассказывала первая статья.
Кажется, что тема слайсов будет развиваться дальше по трем причинам (время для #2pe\analytics):
1. кажется, что микросервисы дошли до Trough of Disillusionment и разговоров о возврате к монолитам становится больше в моем пузыре;
2. ограничивать части монолита нужно, DDD добавляет абстракций, использовать сервисы, декораторы и другие объекты в больших проектах сложно (куча хлама в одном месте). По идее, слайсы как раз и могут решить проблему поддерживаемости, при этом не добавляя проблем распределенных систем;
3. об этом начинают говорить не только в .net но и в js, ruby и других экосистемах.
При этом, я думаю, что подход вряд-ли окажется популярным как микросервисы, но он доступен для любой
экосистемы, даже для rails.