Проектик: питон, asyncio, socket и прочие приблуды

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

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

Mixin-классы, которые описывают поведение определенного функционала, к примеру - BaseSyncConnectable, или BaseAsyncSendRecv. Служат соответственно для создания подключения и отправки/принятия данных (Работа непосредственно по взаимодействию с сетевым устройством/устройствами).

Соглашения по использованию миксинов, или же интерфейсы для написания конкретных реализаций. Являются базовыми абстракциями, которые объединяют в себе определенные миксины в зависимости от мода (sync/async) и типа протокола (например, TCP требует методов connect/accept, которые реализованы в BaseConnectable, а udp обходится простыми send/recv).

Сериализаторы. Структуры, которые приводят пакеты, которые передаются в сети, к определенному единому стандарту для облегчения написания стандартных парсеров. Пример использования - отсечение заголовков MosbusTCP, которые несут скорее техническую, чем пользовательскую информацию (Номер транзакции, функции modbus, прочая техническая история). В "голом" TCP просто кидаются байты.

Структура типа Транспорт. Является объединением сериализатора и миксина. Объедниение происходит путем делегирования, так как нужно заменять сериализатор и миксин в зависимости от требуемого протокола (см. ниже). По-сути, транспорт - это то, как общаются устройства (В соответствии с одноименным 4 уровнем модели OSI)

Протокол. В протокол мы делегируем транспорт и парсеры, и с помощью декораторов (АОП) добавляем функционал/регистрацию протокола по его моду, имени, прочим параметрам уникальным для конкретного протокола (Всегда единое количество параметров).

Немножко объяснения. Пойдем сверху вниз:

Протокол - средство для предоставления пользователю инструмента по использованию сети (Транспорт) в удобном для него формате, с возвратом читабельных данных (Парсер).

Транспорт - средство общения машин на уровне сети, с приведением к единому виду данных в виде байтовой строки

Сериализер - средство для непосредственного приведения данных к единому стандарту.

Миксин - конкретная реализация через нужные средства разработки.

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

Но как использовать данный инструмент для работы с сетями? Для этого предусмотрена система с использованием паттерна фабрики (Factory) и паттерна Устройство (Device):

Factory - класс, который регистрирует и делегирует нужные протоколы с нужными параметрами.

Device - контекстный менеджер для использования приведенных к единому виду протоколов. Он администрирует работу протокола с помощью threading, logging и прочих библиотек "надзора" за сетью для предоставления данных о работе приложения (Debug mode). Так же позволяет юзеру быстро интегрировать нужные протоколы по их названию и параметрам запуска.

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

Надеюсь, пост был информативен для новичков, интересен для титанов IT, и просто помогал скрасить тяжкие дни рабочего офиса во время перерыва. Так же буду признателен за конструктивную критику.

Всем спасибо за уделённое время!