8 шагов построения архитектуры простых систем

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

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

Проблемой маленьких команд или проектов является то, что не все методологии написанные и публикуемые в сети к ним применимы. И команды зачастую не состоят из “ветеранов проектирования” — потому что те просто “не по карману” стартапам и частным командам.

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

Любое решение строится вокруг какого-то процесса — например совершение покупки, или подача заявки, даже публикация поста. Здесь речь идет не только о последовательности действий пользователей — участников будущей системы, но и про внутренние процессы: проверки одной системой, регистрация другой, подготовка публикации и так далее.

Описание процесса лучше делать "сверху вниз" то есть начинать с более высокого уровня детализации, а потом “спускаться" из абстракций в детали. Например:

... а затем:

Здесь можно не бояться добавлять детали не только на текущем уровне детализации, но и возвращаться на “верхний уровень” — добавлять большие блоки и детализировать их. Например:

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

Ввиду того, что на данном этапе отсутствует структура как таковая, я предлагаю использовать простой текстовый редактор например https://docs.google.com/, потому что любой другой инструмент, требующий более структурированного подхода, на текущем этапе будет только ограничивать свободу мысли. Например, если, для того чтобы добавить простую функцию, надо переработать структуру документа, мозг подсознательно начнет оценивать целесообразность затрат и многие мысли не будут зафиксированы. А в IT фраза «Дьявол кроется в деталях» может запомниться как очень дорогой урок.

После того, как описан основной процесс, таким же образом формализуются остальные — служебные процессы, которые зависят от основного.

После того, как список действий определен, становится возможным понять кто и какое действие выполняет. То есть для каждого шага мы определяем исполнителей, кто должен или может делать какое-то действие в рамках процессов.

Для простоты исполнителей можно просто указать в скобках напротив каждого действия:

Таким образом мы не только понимаем кто будет выполнять действия, но и начинаем формировать список интерфейсов и устройств, с которых будут поддерживаться эти действия.

В современном мире, текст не является самым быстрым способом донести структурную информацию, поэтому необходима визуализация работы, проведенной на предыдущих этапах.

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

Несмотря на определенные неудобства, я рекомендую использовать https://app.diagrams.net/, ввиду того, что этот инструмент бесплатный и предоставляет очень много шаблонов, которые окажутся очень полезными для новичков.

BPMN как язык диаграмм, предоставляет очень богатый инструментарий, который… нам с вами не нужен. В рамках объявленного в заголовке масштаба задачи, нам достаточно использования:

Остальное - оставим корпоративщикам.

В итоге получается диаграмма, которую можно согласовать с клиентом.

Диаграмма помогает понять “кто?”, “что?” и “когда?”, однако не отвечает на вопрос “с чем?”.

Для этого нам необходимо построить модель данных - совокупность объектов, их атрибутов и связей между ними. На основании именно этой модели, впоследствии, будет строиться архитектура Базы данных, разбиваться система на сервисы и формироваться форматы вызовов сервисов и многое другое.

Здесь есть следующие понятия:

Для каждого блока “Действие” в нашей диаграмме, необхродимо описать какие именно данные нужны этому участнику процесса для выполнения этого действия. Например:

Этот шаг, выполненный для всех действий позволит сформировать общее понимание всей модели данных с Бизнес-перспективы.

Дальше на основании собственного опыта и подходов самих разработчиков, сюда же добавляются и служебные атрибуты. В скором времени я планирую написать отдельную статью о том, какие из них спасают время при дебаге и разбирательствах (напишите в комментариях, интересно ли это).

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

В качестве инструментов можно использовать все тот же https://app.diagrams.net/, однако для случае, когда связей много а модели простые, я бы предложил использование https://start.jhipster.tech/jdl-studio/ который является окном в мир кодогенераторов и hgjfrnbdyjuj прототипирования и точно заслуживает отдельной статьи. Здесь мы только поскребем по поверхности и используем бесплатный инструмент JDL-studio.

Синтаксис достаточно простой, разобраться может любой новичок минут за 5, тем более что все изменения применяются сразу и диаграмма моделей перестраивается.

Теперь мы должны вернуться к самому первому документу и извлечь из него данные в следующем формате:

Либо, как делается в корпоративных проектах, ввиду сложной иерархии:

Где, для каждого раздела необходимо расписать набор из:

Эта структура позволяет дать более-менее структурированное понимание функций системы “from user perspective”, что очень удобно дизайнерам.

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

Здесь есть множество решений платных и бесплатных, сложный и простых, интерактивных и нет.

На собственном опыте, принимая во внимание распространенность, бесплатность и интерактивность я бы порекомендовал https://www.figma.com/. Единственное, что он не умеет (хотя бы из коробки) - это давать возможность заполнять текстовые поля в режиме Презентации.

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

Мобильные прототипы можно “скачать” и посмотреть как они выглядят на устройстве (обязательно делайте эту проверку)

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

Этот этап вынесен в самый конец неспроста - в ходе демонстрации прототипа, зачастую всплывают изменения в том, кто и в каком устройстве должен что-то делать, что накладывает достаточно драматические изменения в архитектуру API систем и сервисов.

Более того, проектирование API критично еще и потому, что структура API - это контракт между разработчиками разных компонентов, например Front-end и Back-end систем. И управляемость совместной разработки напрямую зависит от того, насколько детально прописаны API-calls, и насколько полно они удовлетворяют вызывающую и принимающую сторону.

На этом этапе, имея на руках формализованный процесс, диаграмма которого показывает точки “соприкосновения” систем, структурированную модель данных, интерфейсы и их функции, разработка архитектуры завершается тем, что команда (или все альтер-эго одного разработчика) совместно прописывает API-calls, расходится и приступает к планомерной разработке итогового решения, имея на руках все, необходимые для этого документы, данные и диаграммы.

Весь этот процесс, в зависимости от сложности проекта, “размера” клиента и количества вовлеченных человек, занимает от одной до двух недель. Но эти затраты ничто по сравнению с теми, которые придется нести в случае, если это процесс не выполнять в каждом проекте. И, по опыту, они окупаются со 100% вероятностью.