Внутренняя система учёта расходных материалов — архитектурное ревью¶

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

Содержание¶

Краткое описание
Цели, требования и ограничения
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация
Решения, компромиссы и риски

Краткое описание¶

Статус¶

partial implementation / historical project

Роль¶

инициатор, автор концепции, разработчик прототипа

Стек¶

Тип: Internal automation / early ERP-like inventory system; Период: ранний этап перехода от администрирования инфраструктурой к разработке внутренних систем

Ценность проекта¶

Лёгкая внутренняя ERP-подобная система для учёта расходных материалов ИТ-отдела - остатки, история движения и планирование закупок.

Цели, требования и ограничения¶

Цели и нецели¶

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

Требования¶

Система должна была позволять:

вести справочник расходников;
фиксировать поступления;
учитывать выдачу и списание;
видеть текущие остатки;
анализировать динамику потребления;
поддерживать планирование закупок;
снизить зависимость от ручного учёта и разрозненных таблиц.

Частично реализованный объём¶

Концепция внутренней системы учёта расходников.
Базовая структура справочников и операций.
Подход к фиксации поступлений и расхода.
Табличная модель для практического учёта.
Использование накопленных данных для планирования закупок.
Переход от хаотичного ручного учёта к более структурированной модели.

Ограничения¶

Модель системы¶

Доменная модель¶

В основе решения лежала простая, но прикладная доменная модель:

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

Модель данных¶

Диаграмма классов¶

classDiagram
    class ConsumableItem {
      id
      name
      sku
      type_id
    }

    class ConsumableType {
      id
      name
    }

    class EquipmentModel {
      id
      vendor
      model
    }

    class StockMovement {
      id
      type
      quantity
      date
      item_id
      consumer_id
      comment
    }

    class Department {
      id
      name
    }

    class Place {
      id
      name
      department_id
    }

    class ConsumerEquipment {
      id
      name
      place_id
      model_id
    }

    ConsumableItem --> ConsumableType
    ConsumableType --> EquipmentModel
    StockMovement --> ConsumableItem
    StockMovement --> ConsumerEquipment
    ConsumerEquipment --> Place
    Place --> Department

API-контракты¶

Архитектура и интеграции¶

Архитектура¶

Архитектурный подход¶

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

Потоки интеграции¶

Безопасность, качество и эксплуатация¶

Модель безопасности и доступа¶

Нефункциональные требования¶

Режимы отказа¶

Оценка масштаба и стоимости¶

Решения, компромиссы и риски¶

Ключевые решения¶

Компромиссы¶

Модульный монолит без преждевременного усложнения¶

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

Ранний прототип vs завершённая ERP¶

На текущем уровне зрелости проекта корректнее рассматривать его как early internal automation prototype, а не как завершённую ERP-систему.

См. также Architecture Decision Records.