Архитектура систем

Единый архитектурный фундамент для разных предметных систем. Общее техническое ядро + индивидуальный предметный контур.

MES, WMS и ERP строятся на одном технологическом фундаменте. Различаются не архитектурой, а предметной областью: производственные операции, складские процессы, управление ресурсами. Это позволяет добавлять модули по мере роста без переписывания ядра.

Технологический стек

Open source-стек, лицензионные платежи вендору не предусмотрены в рамках согласованной модели передачи

Backend

Python, FastAPI, SQLAlchemy. Асинхронные обработчики, Pydantic-схемы, автогенерация OpenAPI.

База данных

PostgreSQL. Реляционная модель, миграции Alembic, резервное копирование, транзакции.

Frontend

Vue.js или чистый HTML/CSS/JS с Tailwind — в зависимости от сложности интерфейса. Серверный рендеринг Jinja2 для SEO-страниц.

Развёртывание

Docker, Docker Compose. On-premise на сервере заказчика или в облаке. Без обязательных облачных зависимостей.

Интеграции

REST API, 1С-интеграция (HTTP-сервисы / обмен файлами), QR/штрихкоды, Честный ЗНАК, ТСД.

Аутентификация

JWT-токены, ролевая модель доступа (RBAC). LDAP/AD — по требованию.

Слои системы

От оборудования до директора — один путь данных

  1. 1. Точка сбора данных — ТСД на складе, планшет в цеху, QR-код на детали, сканер штрихкодов. Данные фиксируются в момент операции, не постфактум.
  2. 2. API-слой — FastAPI. Приём операций, валидация через Pydantic, бизнес-логика, авторизация по ролям.
  3. 3. Модель данных — PostgreSQL. Операции, остатки, заказы, пользователи, роли. Миграции через Alembic.
  4. 4. Интеграционный слой — обмен с 1С, внешние API, выгрузки, ЭТРН, Честный ЗНАК.
  5. 5. Интерфейс — веб-интерфейс для рабочего, мастера, кладовщика, руководителя. Разные роли — разные экраны.
  6. 6. Отчётность и аналитика — выработка по цехам, брак по причинам, остатки, сдельная ЗП. Формируются из данных системы за период.
1. Точка сбора данных ТСД · Планшет · QR · Сканер 2. API-слой (FastAPI) Pydantic · Роли · OpenAPI 3. Модель данных (PostgreSQL) Миграции Alembic · Транзакции 4. Интеграционный слой 1С · ЭТРН · Честный ЗНАК · API 5. Интерфейс (Vue.js / Jinja2) Рабочий · Мастер · Кладовщик · Директор 6. Отчётность и аналитика Выработка · Брак · Остатки · ЗП

Общее ядро и предметные контуры

MES, WMS и ERP — модули на общем фундаменте

MES
Производственные операции
WMS
Складские процессы
ERP
Управление ресурсами
↓
↓
↓
Общее техническое ядро
API (FastAPI) БД PostgreSQL Интеграции Аутентификация Логирование

пример архитектуры, конкретная схема зависит от проекта

Производство, склад и управление ресурсами — связаны. Заказ из ERP запускает маршрутную карту в MES, MES списывает материалы со склада в WMS, WMS отгружает готовую продукцию и закрывает заказ в ERP.

Если это три разных продукта от трёх вендоров — интеграция становится отдельным проектом, дорогим и хрупким. В общем фундаменте данные текут без интеграционных швов.

Можно начать с одного модуля (например, WMS) и добавить MES или ERP позже — без миграции и переписывания.

Развёртывание

On-premise

Сервер на территории заказчика. Данные не покидают периметр. Подходит для промышленных предприятий и задач с требованиями безопасности.

Облако

Развёртывание в облаке заказчика — например, Yandex Cloud, Selectel или AWS. Быстрый старт, масштабирование по нагрузке.

Гибридное

Часть модулей on-premise (учёт, БД), часть в облаке (портал, аналитика). Определяется под требования безопасности.

Хотите разобрать архитектуру под ваш процесс?

На аудите покажу, как ляжет стек на ваши процессы и интеграции

Записаться на аудит

ADR: Общее техническое ядро + индивидуальный предметный контур

ADR — формат записи технических решений с контекстом и компромиссами

TL;DR

Используем единый архитектурный фундамент (API, БД, интеграции, аутентификация) для всех систем, а предметную логику (MES, WMS, ERP) реализуем как независимые модули поверх ядра.

Проблема

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

Контекст

С 2007 года внедрено 80+ систем. Большинство — MES, WMS, ERP для производственных и складских предприятий. Стек: Python, FastAPI, PostgreSQL, Docker. Заказчики требуют on-premise и передачу исходного кода.

Решение

Разделить на два слоя: (1) общее техническое ядро — API-фреймворк, ORM, аутентификация, логирование, интеграционный шлюз; (2) предметные контуры — модули MES, WMS, ERP со своей логикой, таблицами и API-эндпоинтами. Ядро переиспользуется между проектами, контуры пишутся под конкретный процесс.

Компромиссы

  • Плюс: новый проект стартует с готовым ядром — MVP за 6–12 недель, а не с нуля.
  • Плюс: изменение в MES не затрагивает WMS — модули изолированы.
  • Плюс: можно начать с одного модуля и добавить другие позже — без миграции.
  • Минус: ядро нужно поддерживать и обновлять across проектов — есть риск расхождения версий.
  • Минус: не каждый проект укладывается в ядро — иногда требуется доработка самого ядра.
  • Минус: больше абстракций, чем при написании «в лоб» — выше порог входа для нового разработчика.

Результат

80+ систем в эксплуатации на одном архитектурном фундаменте. Заказчики получают систему быстрее и дешевле, чем при разработке с нуля, и могут масштабировать, добавляя модули.

Ограничения

  • Архитектура — пример. Конкретная схема слоёв и модулей зависит от процессов предприятия.
  • Ядро не является open-source продуктом — это внутренний фундамент студии.
  • Не подходит для проектов, где требуется интеграция с существующей корпоративной платформой (SAP, 1С:ERP) как ядром.

Источники

  • Кейс: MES для завода ЮСМ — 50+ пользователей, 3+ года эксплуатации
  • Кейс: WMS для склада РефГо — рост 50 → 1500+ заказов
  • Кейс: WMS для Людиновокабель — 10 000+ SKU, 22 000 м²
  • Страница /evidence — метрики с методикой измерения
Выберите удобный способ
Telegram