Трудясь над каждой операцией на протяжении многих лет, я стремился улучшать свои навыки. Я успешно преодолевал текущие проблемы, но на их месте всегда появлялись новые.
Обычно эти проблемы были связаны с состоянием. Как бы тщательно я ни разделял все контроллеры и менеджеры, всегда находился фрагмент кода, которому требовался доступ к состоянию. Эти инциденты приводили к сбою первоначального проекта.
Повторение одного и того же действия в ожидании разных результатов — настоящее безумие. И я, в конце концов, решил положить этому конец и попробовать что-то другое.
В поисках альтернативы
Я изучал все варианты, какие только смог найти. Я разбирал успешные библиотеки в поисках подсказок по оптимизации проигрывателя.
В конце концов, я убедил свою команду приступить к созданию совершенно другой архитектуры для следующей итерации проигрывателя. Это был огромный риск. Мы действовали вслепую, руководствуясь лишь амбициями и упрямством, порожденным отчаянием. Провал был недопустим.
Бизнес-логика в веб-проекте. Проблема понимания бизнес-логики клиентских проектов. #bll #biz
И мы преуспели. Мы справились с задачей в рекордно короткие сроки. Разработанный проигрыватель был надежным: мы годами обходились без наращивания основной функциональности. Он был масштабируемым: мы добавляли функции без установления взаимозависимостей. Он был расширяемым: у других команд из других компаний получалось без проблем его модифицировать.
Более того, наша команда из 4–6 инженеров оказалась более продуктивной, чем другие команды из 20 человек.
Однако этот проигрыватель и его инновационный дизайн не выжили в корпоративных условиях. Поэтому хочу поделиться опытом, с трудом приобретенным моей командой.
Принцип № 1. Инкапсулируйте бизнес-логику, а не состояние
Что будет, если централизовать все части устойчивого состояния, просто убрав их из классов?
Нам пришлось задать себе этот вопрос, приступая к разработке проигрывателя. Мы собирались создать некую вариацию Redux, но в больших масштабах. Мы верили, что наличие 1 легкодоступного источника истины решит огромное количество проблем.
С чем мы остались после извлечения состояния? С большим количеством бизнес-логики, которая не имела смысла, потому что была распределена по приложению.
И тут я понял, что все дело в бизнес-логике.
Состояние — это просто временная связь между различными частями бизнес-логики.
Логическая модель: определение приложения и планирование
Второй этап процесса проектирования приложений COM+ — разбить концептуальную модель на логические уровни трехуровневой архитектуры: уровень представления или пользовательские службы; средний уровень или бизнес-службы; и уровень данных или службы данных. Если вы не знакомы с трехуровневой архитектурой, см. статью «Использование модели архитектуры Three-Tier».
Начните этот процесс, просмотрев концептуальную модель существительных и глаголов. Существительные часто могут преобразовываться в бизнес-объекты (классы), а команды, связанные с ними, могут преобразовываться в действия (методы классов). Хотя может быть трудно определить все существительные как бизнес-объекты, упущения или ошибки становятся очевидными к тому времени, когда вы завершите логическую модель.
КАК ПИСАТЬ БИЗНЕС ЛОГИКУ В DJANGO PYTHON? КАК СОЗДАТЬ ПРАВИЛЬНЫЕ СЕРВИСЫ В DJANGO?
Большинство бизнес-объектов будут находиться на уровне бизнес-служб, а остальные объекты разделены между объектами пользовательского интерфейса на уровне служб пользователей и объектами данных на уровне служб данных. При создании логической модели с помощью трехуровневой архитектуры учитывайте следующее:
- Некоторые существительные в концептуальной структуре не будут представлять фактические физические фрагменты данных, но могут представлять действие по системе или роли бизнес-объекта в системе. Бизнес-объект также может быть службой, которая выполняет какой-то системный контроль, например идентификатор входа для обеспечения безопасности.
- Избегайте создания расплывчатых бизнес-объектов путем чтения между строками в концептуальной модели. Такие бизнес-объекты могут быть неправильными, и их следует тщательно рассмотреть, прежде чем включать их в логическую модель. Если они отображаются правильно, добавьте их в концептуальную модель явным образом.
- Избегайте создания бизнес-объектов, которые выражают одну и ту же информацию или функцию; дублирование может быть дорогостоящим с точки зрения скорости и производительности приложения.
- Определите зависимости объектов. Некоторые существительные в концептуальной модели могут быть просто атрибутами других бизнес-объектов. Определите, может ли атрибут существовать независимо. В этом случае он должен стать собственным бизнес-объектом; Если нет, его следует объединить с соответствующим бизнес-объектом.
- Избегайте создания бизнес-объектов, которые пытаются сделать слишком много. Перегрузка бизнес-объектов может означать больше времени, затрачиваемого на разделение кода позже и может стать головной болью обслуживания. Отдельные объекты в концептуальной модели не должны объединяться; они должны оставаться отдельными бизнес-объектами. Вы можете обрабатывать любые сходства с помощью кода для делегирования их общих функций бизнес-объекту.
- Удалите все бизнес-объекты, которые не используются в сценариях использования. Если объекты предназначены для дальнейшего роста, рассмотрите возможность их реализации после завершения первоначального приложения.
На этом этапе можно начать думать с точки зрения компьютеров и кода. Из этих бизнес-служб определите функции отображения и ввода, которые необходимо предоставить в качестве пользовательских служб. Определите таблицы и хранимые процедуры, которые необходимо предоставить в качестве служб данных. Чтобы завершить логическую модель, определите интерфейсы для каждой службы и включите определения каждого поля данных и их правила проверки. Также включают все функции, их синтаксис и их параметры.
Определение службы или объекта не должно включать какой-либо аспект физической реализации. Цель состоит в том, чтобы предоставить четкое руководство для разработчиков логических компонентов для работы и для того, чтобы другие программисты могли кодировать части приложения, которые могут использовать компонент до его завершения. В структуре логической модели необходимо документировать каждый экран, функцию и объект. Не переходите к физической модели или реализации, пока не будете соответствовать этим критериям. Если вы продолжаете работу, пока концептуальная модель и логическая модель не находятся в соглашении, у вас будут серьезные проблемы позже в цикле разработки.
Добавочная разработка приложения COM+ является распространенным явлением. Это включает в себя создание подмножества конечных известных компонентов и их тестирование с помощью каждого уровня приложения: клиентских, бизнес-уровней и уровней данных— до хранения данных. Эта рабочая модель дает представление о дополнительных требованиях клиентов и реализации. Часто эта рабочая модель тестируется на одном компьютере.
Источник: learn.microsoft.com
Облако моего приложения: параметры бизнес-логики
Когда вы пишете приложение среднего размера для Windows, обычно это один большой или несколько небольших проектов, которыми вы управляете в Visual Studio. Проект обычно содержит все, что вам нужно, от внешнего интерфейса до бизнес-логики и иногда даже базы данных.
Иногда приложение, как и мое, может не всегда соответствовать передовым практикам, в результате чего вы добавляете бизнес-логику во внешний пользовательский интерфейс, как показано на следующем рисунке.
Мое приложение в его будущем состоянии будет сервисом. Таким образом, я могу писать нативные или веб-приложения, которые не содержат основной бизнес-логики. Кроме того, я могу даже открыть свое приложение, чтобы сторонние разработчики могли воспользоваться этой услугой. Вы можете увидеть диаграмму в маркетинговом стиле того, чего я пытаюсь достичь, на следующем изображении.
Чтобы создать эту новую службу приложений, мне пришлось долго и упорно думать о том, как спроектировать бизнес-логику для моего приложения. Вот как мне удалось пробраться через море вариантов и найти варианты, которые подходят для моего приложения — во всяком случае, прямо сейчас?
Варианты бизнес-логики
Веб-приложения Azure (слишком большие)
Веб-приложение Azure — это, по сути, масштабируемое веб-приложение, которое вы создаете в Visual Studio и загружаете в Azure (при условии, что это не обязательно должна быть Visual Studio, но давайте посмотрим правде в глаза, пользователи VS — это целевая аудитория Microsoft). Это приложение может содержать бизнес-логику, представления (веб-интерфейс) и другие элементы, составляющие ваше приложение. Создание веб-приложения похоже на создание приложения для Windows, но с браузером в качестве внешнего интерфейса.
Хотя я хочу, чтобы мое приложение поддерживало любую операционную систему, мне, безусловно, нужна версия для браузера и версия надстройки Office Web, размещенная в Интернете. По этим причинам я могу создавать веб-приложения для внешнего интерфейса (а может и нет, так как я играю с одностраничными приложениями в качестве еще одного варианта).
Технически я могу написать бизнес-логику для своего приложения в виде веб-приложения Azure. Я могу предоставлять различные службы решениям в сети Azure и за ее пределами. Однако, если я открываю веб-приложение для внешнего использования, мне нужно написать кучу пользовательского кода для управления такими вещами, как безопасность и другие низкоуровневые элементы.
Функции Azure (слишком маленькие)
Когда я впервые задумался об облачном преобразовании своего приложения, я читал множество отчетов о том, что так называемые — это путь будущего, а функции Azure и функции AWS Lamba лидируют. Функции казались идеальным подходом к реализации моего приложения. Это небольшие фрагменты кода, которые выполняют почти любое действие, которое вы можете закодировать.
Функции работают аналогично службам приложений, таким как Zapier и IFTTT, где что-то запускает их, и они выполняют быструю функцию. Например, вы можете написать функцию, которая запускается при появлении новой записи в базе данных, веб-перехватчике, таймере или каком-либо другом внешнем триггере.
Стало понятно, что для использования функций мне придется разбивать свое приложение на вот такие мелкие составные части. Учитывая объем моего приложения, я не думаю, что стоит использовать функции в качестве основного решения для разработки сервисов моего приложения. Тем не менее, функции Azure не умерли для меня. Я думаю, что они найдут место в моем коде в качестве небольших «вспомогательных» функций, выполняющих уникальные операции, которые мне не нужны в базовом коде. Читайте дальше, и я расскажу, как функции, вероятно, вписываются в общую картину.
Приложения Azure API (в самый раз)
Приложения Azure API позволяют создавать бизнес-логику для вашего приложения, которое обрабатывает запросы, поступающие от других приложений. Приложения API — это своего рода старший брат Функций Azure, позволяющий создавать многофункциональные API (интерфейсы прикладного программирования), к которым будут обращаться другие приложения. Например, я могу создать веб-приложение, мобильное или настольное приложение, которое отправляет запрос в API. API определит, как обработать запрос, выполнит соответствующую бизнес-логику, а затем вернет результат.
Что мне нравится в приложениях API, так это то, что они маленькие, компактные и отличаются бизнес-логикой от других моих приложений. Кроме того, вы можете защитить API, используя Azure Active Directory для защиты службы.
Собираем все вместе
API — это, конечно, один из элементов всего приложения. Как я упоминал ранее в этой статье, я могу использовать веб-приложения для интерфейсных веб-элементов моего приложения.
Я также могу использовать Функции Azure. Возможно, я захочу предложить несколько небольших сервисов, которые просто не стоит кодировать в основной бизнес-логике моего приложения. Например, предположим, что пользователь хочет, чтобы копия его книги автоматически публиковалась в интернет-магазине электронных книг, отправлялась по электронной почте или публиковалась в учетной записи Dropbox. Мой API должен быть в состоянии передать эту рабочую нагрузку небольшим функциям, которые подходят для выполнения этих действий после обработки.
Имея все это в виду, теперь я могу начать перенос бизнес-логики моего приложения на набор API. По сути, я предполагаю, что мои приложения получат доступ как минимум к двум API. Первый API будет преобразовывать один документ в различные форматы электронных книг. Другой API будет выполнять гораздо более сложную задачу по упаковке нескольких файлов Microsoft Word в одну электронную книгу.
Конечно, оба этих API делают очень похожие вещи, поэтому мне, возможно, придется создать дополнительные «внутренние» API, которые содержат общую бизнес-логику.
Когда я настрою свои первые API, я планирую поделиться своим опытом в будущих статьях и, если потребуется, в некоторых видеороликах. Пожалуйста, прокомментируйте, если у вас есть какие-либо вопросы. Как всегда, я также рад услышать ваше личное мнение или идеи.
Другие статьи из этой серии см. по адресу:
- Путешествие начинается
- Должен Git Git
- Демистификация надстроек Microsoft Office
Источник: progler.ru
