Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.
На Хабре не так много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации. Но об этом есть серия статей у Камиля Гржибека. Сегодня поделюсь переводом первой из них.
Есть вопрос, который я никак не могу раскусить. Казалось бы, по нему есть масса информации: книги, статьи, доклады. Но сложность и многогранность темы не позволяет сразу ухватить суть. Поможешь мне в этом?
Чтобы действительно понять сложную тему, нужно прочитать и обдумать множество источников. Прелесть в том, что каждый из них предоставляет одну и ту же информацию по-своему и какой-то из этих подходов может сработать именно для тебя. Так что давай и я попробую внести свой вклад в общее информационное пространство. Так какой у тебя вопрос?
Традиционно процесс разработки ПО сравнивается со строительством. Термин «архитектор» только укрепляет ассоциативную связь между этими процессами. Но современные реалии сделали эту модель неактуальной, потому что есть механизмы, которые она объяснить не может:
Если мы делаем какой-то физический объект или продукт, то почему ПО никогда не считается законченным?
Если мы говорим об инженерных решениях, то почему мы никогда не можем уверенно планировать наперед?
Если мы — архитекторы или строители, то почему так много проектов заканчиваются полным провалом?
И наконец, при наличии множества советов, best practices, принципов, книг и докладов о разработке ПО, почему так много проектов превращаются в невыносимое место для работы?
Предлагаю близкий к тексту перевод блестящего доклада Сары Мэй «Livable code», где она рассматривает все эти вопросы.
Примерно такие же эмоции я и мои коллеги испытывали, когда начинали работать с Docker. В подавляющем большинстве случаев это происходило от недостатка понимания основных механизмов, поэтому его поведение казалось нам непредсказуемым. Сейчас страсти поутихли и вспышки ненависти происходят все реже и все слабее. Более того, постепенно мы на практике оцениваем его достоинства и он начинает нам нравиться… Чтобы снизить степень первичного отторжения и добиться максимального эффекта от использования, нужно обязательно заглянуть на кухню Docker'a и хорошенько там осмотреться.
По своему опыту знаю, что на начинающего разработчика, особенно осваивающего профессию самостоятельно, сваливается огромный объем информации. На первых порах знаний и опыта практически нет и новую информацию, получаемую из книг и статей, при усвоении не с чем связать в своей памяти. И, если практические знания постоянно находятся в использовании, то базовые, теоретические вещи трудно укладываются и без освежения достаточно быстро выветриваются из головы новичка. Осознав такую неутешительную тенденцию, я стал интересоваться вопросом повышения скорости чтения и эффективности запоминания. В этой статье я хочу поделиться с вами результатами изучения этого вопроса путем описания наиболее интересных, с моей точки зрения, моментов из нескольких прочитанных книг.
