Архитектурные решения перед генерацией кода

Тип проекта

Перед бегом lino project new, определить цель системы. Внутренний административный проект, мультитенантный SaaS, общедоступный API и распределенная платформа имеют разные потребности.

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

Это решение также определяет, какие опасения должны возникнуть в первый день. SaaS не может рассматривать tenantа как просроченную деталь; публичный API не может родиться без ограничения ставок и четких контрактов; решение с событиями должно думать о Outbox, идемпотентности и наблюдаемости; приложение с несколькими культурами должно с самого начала избегать разбросанных строк.

При создании основы запишите основные параметры: поддерживаемые языки и региональные параметры, распределенный кэш, асинхронную связь, анализаторы кода, тип базы данных, наличие веб-приложения, аутентификацию, tenantа и рабочего процесса. Эти параметры влияют на пакеты, шаблоны, AppHost, параметры, secrets, созданные проекты и усилия, необходимые для последующего изменения архитектуры.

Модульные и модульные монолитные микросервисы

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

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

Lino поддерживает оба пути. Решение должно учитывать сферу деятельности и оперативные возможности команды, а не только технические предпочтения. Микросервисы требуют автоматизации развертывания, распределенной наблюдаемости, управления версиями контрактов, отказоустойчивости сети, обмена сообщениями, повторной обработки и управления данными. Если команда еще не может выполнить это безопасно, слишком раннее распространение часто увеличивает риск.

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

Ограничения сервисов и модулей

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

• Catalog: продукты, категории, коммерческая информация и данные, используемые отделом продаж.
• Sales: заказы, корзина, прикладные цены, снимки и коммерческий поток.
• Stock: доступность, бронирование и движение.
• Security: пользователи, роли, разрешения, аутентификация и токены.

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

Если одному модулю нужны данные из другого, выберите между API, событием интеграции, shadow entity или изменением формы границ. Прямой доступ к database другого модуля является признаком структурной связи. Даже если два модуля выполняются в одном процессе и используют одну и ту же физическую базу данных, схема, проекты персистентности и контракты должны защищать бизнес-границы.

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

Сознательный технический долг

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

В SaaS или модульной системе самый опасный технический долг — это не просто длинный метод. Именно долг ограничивает эволюцию: модули, которые не могут изменяться отдельно, данные tenantов без надежной изоляции, secrets внутри репозитория, чувствительные конечные точки без ограничений, события без повторной обработки или интеграции без четкого контракта.

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

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

Коммуникационные стратегии

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

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

• Синхронный вызов: хорош для немедленных запросов и приемлемой зависимости. Избегайте длинных каскадов.
• Domain Event: внутренняя реакция в пределах того же предела применения.
• Integration Event: связь между модулями, службами или системами, обычно с помощью Outbox.
• Shadow Entity: Минимальная локальная копия для консультации и проверки без прямой зависимости от producer.
• Внешняя интеграция HTTP: подходит для сторонних сервисов, с тайм-аутом, повтором, журналами и обработкой сбоев.

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