Когда серводвигатели встречаются с программной архитектурой: разговор о ядре

Представьте себе этот сценарий. Вы сконструировали прецизионную роботизированную руку, каждый сустав которой приводится в движение высокопроизводительным серводвигателем.мощностьСкорость отклика сервопривода вас очень удовлетворит. Аппаратное обеспечение работало безупречно, но управляющее им программное обеспечение давало сбои. Добавьте новую функцию, и вся система пошатнется; измените кусок кода, и в совершенно другом модуле выскакивают неожиданные сбои. Система становится все более громоздкой, как машина со слишком большим количеством аксессуаров, но теряет первоначальную ловкость.

Речь идет не только о программном обеспечении, верно? Речь идет о том, как организовать ядро. Ваше механическое устройство имеет четко определенную структуру: двигатель, трансмиссия и контроллер выполняют свою работу. А что насчет вашего программного обеспечения? Ясна ли его «основная структура»?

Синдром «большого комка грязи» и потеря ядра

Многие проекты начинаются с амбиций. Но поскольку требования продолжали расти, как список деталей, код бизнес-логики, пользовательского интерфейса и доступа к данным стал запутанным. Это похоже на беспорядочную спайку платы управления серводвигателем, источника питания и проводки датчика — временно это может сработать, но вы хотите настроить один из параметров? Удачи, может спровоцировать каскад коротких замыканий.

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

Доменно-ориентированный дизайн: отображение сложного мира

Как определить это «ядро»? Проектирование, управляемое предметной областью (DDD, проектирование, управляемое предметной областью) обеспечивает способ мышления. Неважно, какой язык программирования вы используете, но, как опытный инженер-механик, сначала задайте фундаментальный вопрос: какую проблему мы решаем?

Это точное управление движением? Это автоматизированное планирование сборочной линии? DDD выступает за то, чтобы разработчики и эксперты в предметной области (например, инженер, который лучше всего понимает работу вашего двигателя) использовали общий язык, продолжали диалог и совершенствовали «основные области» системы. Затем вокруг этого ядра, как при планировании модулей машины, определите четкие ограниченные контексты. Какие правила лежат в основе управления двигательными движениями? Что относится к управлению периферийными устройствами?

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

Микросервисы: модульность модулей в независимо функционирующие блоки.

Теперь предположим, что с помощью DDD вы определили четкие бизнес-модули: обработка заказов, управление запасами, мониторинг в реальном времени... Каждый модуль имеет свои четкие обязанности и границы. Как сделать их по-настоящему технически независимыми?

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

Что это дает? Представьте, что каждый сустав вашей роботизированной руки состоит из независимыхмощностьИнтеллектуальные сервоприводы, каждый со своим микроконтроллером. Вы можете улучшить управление моторами на запястье по отдельности, без необходимости выключать и перезапускать всю руку. Если сустав перегружен, вы можете увеличить мощность для него индивидуально. Возможны гибкость, независимое развертывание и разнообразие технологий.

Это выбор, но также и партнер: танец между DDD и микросервисами.

Итак, DDD или микросервисы? Нет, больше похоже на сотрудничество. DDD помогает найти «душу» и модульное деление программной системы (что делать, как разделить); микросервисы предоставляют мощные технические средства для достижения такого разделения (как его построить и запустить).

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

Кто-то спросил: «Проект у нас небольшой, надо ли еще об этом думать?» Задумайтесь, даже если это небольшое устройство автоматизации, вы обязательно сначала спланируете расположение и подключение двигателей, датчиков и контроллеров, а не складываете их хаотично. Четкая ментальная структура может привести к долгосрочной гибкости и контролю, независимо от размера проекта. Речь идет о том, как он построен, а не о его масштабе.

Еще одна распространенная путаница: «Добавит ли это много первоначальных усилий?» Да, требуется время, чтобы глубоко понять предметную область. Но это все равно, что рисовать подробные инженерные чертежи перед началом строительства. Чего он избегает, так это дорогостоящей «переделки» или даже «реконструкции», вызванной структурным хаосом в более поздний период. Ранние инвестиции в ядро ​​приводят к долгосрочной скорости разработки и стабильности системы.

Пусть архитектура служит сути

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

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

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

Основанная в 2005 году, компания Kpower занимается профессиональным производителем компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в модульной технологии привода, Kpower объединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, чтобы предоставить эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.