Логика бизнеса что это такое

Дорогие читатели, в 100% случаев вы используете логику для того, чтобы разобраться в том, как работает продукт, который вы делаете и вам кажется, что именно это и есть UX. Основную часть того самого UX составляет бизнес-логика. Скорее всего вы спросите, почему дизайнера вообще должен волновать вопрос бизнеса. Ну логика-то ладно, а что такое бизнес-логика?

Давайте разберемся, что же такое бизнес-логика:

Бизнес-логика описывает работу всех бизнес-процессов, существующих в продукте.

Воу-воу-воу, полегче.. Это же и есть UX!

И да и нет. Под термином «Бизнес-логика» действительно понимают UX, но есть существенный нюанс.

Обычно к UX-дизайну относятся только пользовательские сценарии. Тогда как бизнес-логика описывает именно бизнес-процессы, происходящие под капотом UX с сугубо технической точки зрения.

Если бизнес-логика отвечает на вопрос:

«Как продукт должен работать технически?»

То UX-дизайн отвечает на вопрос:

Логика. Основы Логики. Логическое Мышление

«Как пользователь будет пользоваться продуктом и как сделать этот процесс максимально удобным и быстрым?».

Наглядная разница

UX-дизайн рассматривает ситуации (сценарии), с которыми сталкивается пользователь в процессе использования продукта; проблемы, которые продукт должен решить, чтобы им было интересно, выгодно или, как минимум, удобно пользоваться.

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

UX-дизайн

То, как видит логику работы части приложения UX-дизайнер.

Пользователь очень хочет смуззи!
Он открывает приложение.
Выбирает смуззи, указывает количество и нажимает кнопку «Купить»
Ввводит адрес доставки, адрес проверяется, переходит к оплате смуззи.
Оплачивает смуззи.
Получает подтверждение покупки и видит информацию о дате и времени доставки, и ждет курьера.

Бизнес-логика

То, что должен видеть хороший UX-дизайнер и продакт менеджер.

Пользователь авторизован / не авторизован
Пользователь выбирает смуззи из всех доступных на данный момент
Пользователь указывает характеристики смуззи
Система проверяет, что для смуззи есть ингредиенты и запускает пользователя в процесс покупки смуззи.
Пользователь указывает адрес доставки.
Система проверяет условия доставки и можно ли вообще доставить смуззи за МКАД по указанному адресу.
Пользователь переходит к оплате смуззи.
Если пользователь авторизован, то его направляют на выбор способа оплаты.
Если пользователь не авторизован, то его направляют на регистрацию.
Пользователь выбирает способ оплаты.
Пользователь указывает «Оплата наличными». Пользователь может выбрать и другой вариант.
Пользователь указывает «Оплата банковской картой».
Пользователь вводит данные банковской карты и нажимает на кнопку «Оплатить».
Платежный шлюз проверяет реквизиты платежа
Платежный шлюз принимает оплату и сообщает системе, что платеж принят.
Заказ поступает в ближайшую к клиенту смуззишную.
Заказ готовится.
Заказ готов и передается курьеру.
Курьер доставляет заказ пользователю.
Курьер отмечает факт доставки заказа.
Данные о завершении заказа попадают в систему.
Система направляет пользователю предложение оценить сервис.

В реальной жизни бизнес-процесс устроен несколько сложнее, но общая идея и различие с UX-дизайном должны быть понятно.

Что такое бизнес-логика и как ее изолировать

Тэйк эвэй

Термин «Бизнес-логика» вы вряд ли услышите в стартапе, нацеленном на продажу смуззи, зато этот термин в широком ходу в B2B и интеграторах.

Теперь вас точно не испугаешь замысловатым вопросом «А как устроена бизнес-логика?». Помните, что бизнес-логика – это про весь механизм работы продукта, а UX-дизайном является лишь то, что по факту увидит пользователь в интерфейсе, в email и sms, отправленные вашим продуктом.

Всем бобра! ❤️

Источник: teletype.in

ООО «ЛОГИКА БИЗНЕСА» ИНН 7735571356 , ОГРН 1107746692195

ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ «ЛОГИКА БИЗНЕСА» 7735571356

Действующее

Уровень риска (ЦБ РФ)
Налоговый риск
Выберите подходящий тариф Онлайн оплата Онлайн оплата
Частный 24 часа
МИНИМАЛЬНЫЙ Частный 24 часа (24 ЧАСА)
МИНИМАЛЬНЫЙ 290 ₽ 24 ЧАСА Сравнение тарифов

Частный 1
МИНИМАЛЬНЫЙ Частный 1 (1 МЕС)
МИНИМАЛЬНЫЙ 990 ₽ – 500 490 ₽ 1 МЕС Сравнение тарифов + База клиентов 100

Частный 12
МИНИМАЛЬНЫЙ Частный 12 (12 МЕС)
МИНИМАЛЬНЫЙ 4900 ₽ – 1910 2990 ₽ 12 МЕС Сравнение тарифов + База клиентов 1 000

Тарифы рассчитаны на одно рабочее место
При оплате Вы соглашаетесь с офертой
Посмотреть все тарифы

Выставить счет на организацию Больше возможностей для бизнеса! Выбрать тариф

Остались вопросы? Задайте их нашим специалистам! Задать вопрос
Дата регистрации 25.08.2010 2010-08-25
ОГРН 1107746692195 от 25.08.2010

ИНН / КПП 7735571356 / 772801001

Основной вид деятельности 62.09 Деятельность, связанная с использованием вычислительной техники и информационных технологий, прочая Все виды деятельности (13)

Дополнительные ОКВЭД

Юридический адрес История 117342, г. Москва, вн.тер.г. Муниципальный Округ Коньково, ул Введенского, д. 1А, этаж 4 СЕКЦИЯ 1, ком. 403
получен 04.03.2021
Осмотреть здание

Руководитель Юридического Лица История Генеральный Директор Касимов Игорь Родомирович Доступен отчет ИНН 773500724321 действует с 19.04.2023

Учредители История Уставный капитал 100 000 руб.
, ИНН 7735006058 Доля: 100 000 ₽ (100%) c 25.05.2021

#Доля (%)Доля (руб.)УчредительИННДата

100%

100 000

АКЦИОНЕРНОЕ ОБЩЕСТВО «УПРАВЛЯЮЩАЯ КОМПАНИЯ «АЙТИ»

7735006058

25.05.2021

Специальный налоговый режим Не применяется Коды статистики
ОКПО 67979329
ОКТМО 45902000000
ОКАТО 45293566000
ОКОГУ 4210014
ОКОПФ 12300
ОКФС 16
Данные реестра субъектов МСП
Среднее предприятие, 101—250 человек Реестр получателей поддержки
Числится (9)

Единый реестр субъектов малого и среднего предпринимательства – получателей поддержки

Форма поддержки: Финансовая поддержка Вид поддержки: Предоставление субсидий и грантов Размер поддержки: 10000000.00 руб. Даты поддержки: 09.08.2021 / 30.12.2021 Поддержка предоставлена от: ДЕПАРТАМЕНТ ПРЕДПРИНИМАТЕЛЬСТВА И ИННОВАЦИОННОГО РАЗВИТИЯ ГОРОДА МОСКВЫ ИНН 9710068955 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Консультационная поддержка Вид поддержки: Консультационные услуги по мерам государственной поддержки Размер поддержки: 0.25 ч. Даты поддержки: 24.03.2023 / 24.03.2023 Поддержка предоставлена от: ФОНД «МОСКОВСКИЙ ИННОВАЦИОННЫЙ КЛАСТЕР» ИНН 9710075695 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Консультационная поддержка Вид поддержки: Консультационные услуги по мерам государственной поддержки Размер поддержки: 0.25 ч. Даты поддержки: 01.04.2022 / 01.04.2022 Поддержка предоставлена от: ФОНД «МОСКОВСКИЙ ИННОВАЦИОННЫЙ КЛАСТЕР» ИНН 9710075695 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Финансовая поддержка Вид поддержки: Предоставление субсидий и грантов Размер поддержки: 24753048.47 руб. Даты поддержки: 23.06.2022 / 19.07.2022 Поддержка предоставлена от: ДЕПАРТАМЕНТ ПРЕДПРИНИМАТЕЛЬСТВА И ИННОВАЦИОННОГО РАЗВИТИЯ ГОРОДА МОСКВЫ ИНН 9710068955 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Информационная поддержка Вид поддержки: Предоставление информации Размер поддержки: 0.40 ч. Даты поддержки: 31.05.2021 / 31.05.2021 Поддержка предоставлена от: ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ГОРОДА МОСКВЫ «МАЛЫЙ БИЗНЕС МОСКВЫ» ИНН 7703766666 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Консультационная поддержка Вид поддержки: Консультационные услуги по мерам государственной поддержки Размер поддержки: 0.25 ч. Даты поддержки: 01.06.2021 / 22.06.2021 Поддержка предоставлена от: ФОНД «МОСКОВСКИЙ ИННОВАЦИОННЫЙ КЛАСТЕР» ИНН 9710075695 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Консультационная поддержка Вид поддержки: Иные консультационные услуги Размер поддержки: 1.00 ч. Даты поддержки: 06.05.2020 / 06.05.2020 Поддержка предоставлена от: ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ГОРОДА МОСКВЫ «МАЛЫЙ БИЗНЕС МОСКВЫ» ИНН 7703766666 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Консультационная поддержка Вид поддержки: Иные консультационные услуги Размер поддержки: 1.00 ч. Даты поддержки: 29.04.2020 / 29.04.2020 Поддержка предоставлена от: ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ГОРОДА МОСКВЫ «МАЛЫЙ БИЗНЕС МОСКВЫ» ИНН 7703766666 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Форма поддержки: Консультационная поддержка Вид поддержки: Консультационные услуги по мерам государственной поддержки Размер поддержки: 0.25 ч. Даты поддержки: 05.10.2022 / 05.10.2022 Поддержка предоставлена от: ФОНД «МОСКОВСКИЙ ИННОВАЦИОННЫЙ КЛАСТЕР» ИНН 9710075695 Есть ли информация о нарушении(ях) порядка и условий предоставления поддержки:
Нет Связано(ы) ли нарушение(я) с нецелевым использованием средств поддержки:
Нет

Источник: zachestnyibiznes.ru

Home

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

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

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

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

Рассмотрим вопрос рационального выбора варианта организации бизнес-логики. Наша основная цель — научиться избегать грубых ошибок за счет применения простой схемы выбора варианта.

Как мы выбираем?

«Святая простота»

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

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

«Идеологический подход»

Также распространенный, но недалеко ушедший от предыдущего способ писания программ: «Потому что правильно!». Разработчик, возможно, прочитал книгу по данной технологии и с этого момента всегда делает так, как в этой книге велено (варианты — изучил «суперуниверсальный» шаблон, скачал «рекомендуемый» пример и т.д.). Здесь личные предпочтения принимают форму твердой убежденности в «правильности» того или иного подхода.

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

Проблемы сознательного выбора

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

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

В результате разработчики начинают кодировать в соответствии с подходами, перечисленными выше. На крайний случай это называется «быстрое прототипирование» либо «наши ребята за один вечер любую задачу порвут на британский флаг». Впоследствии тем же ребятам приходится проявлять чудеса изобретательности, чтобы справиться с проблемами, возникающими из-за несоответствия архитектуры требованиям, предъявляемым к программной системе. За это программист получает отдельное спасибо, обычно заслуженное. И только он сам понимает реальную степень кривизны своего решения и осознает, что «если б было время подумать тогда, в самом начале. можно было бы так красиво сделать. а теперь уж не переделаешь. ». Но на следующем проекте повторяется та же история.

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

Из чего мы выбираем

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

Однако все чаще предпринимаются попытки систематизации и классификации подходов к проектированию для описания профессионального опыта в этой области. Один из способов систематизации приемов и методов проектирования структуры программных систем — шаблоны проектирования или шаблоны архитектуры (также называемые в русском переводе «паттернами», от англ. pattern — образец, модель, шаблон) [1], [2]. В частности, существует три типовых подхода к организации бизнес-логики, называемых сценарий транзакции, модель предметной области и модуль таблицы. Данные подходы в деталях рассмотрены в [1] (вплоть до фрагментов программного кода). Здесь мы рассмотрим основные особенности этих типовых решений и на их примере сформулируем соображения по выбору варианта организации бизнес-логики для проектируемой системы.

Сценарий транзакции (функциональный подход)

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

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

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

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

Модель предметной области (объектный подход)

Этот подход наиболее сложен в реализации, но и наиболее продуктивен. Разрабатывается объектная модель предметной области — по крайней мере, для основных понятий. Например, для интернет-магазина могут быть созданы объекты «клиент», «товар», «корзина», «заказ» и т.д.

Вместо того, чтобы помещать бизнес-логику расчета стоимости в одну или несколько процедур, для каждого объекта реализуется функциональность исходя из зоны ответственности этого объекта. Например, объект «заказ» содержит алгоритм вычисления стоимости заказа на основе цен входящих в него товаров, при этом алгоритмы определения цен на товары реализуются отдельно, в объектах «товар». Если для разных товаров применяются разные алгоритмы вычисления цены, это достаточно легко реализовать в модели за счет создания разных типов товаров.

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

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

Однако за все приходится платить. В случае объектного подхода за исключительную гибкость приходится платить необходимостью выработки определенного, своеобразного стиля мышления. Новичкам приходится затрачивать много времени даже на то, чтобы разобраться в имеющейся объектной структуре (например, в шаблоне), не говоря уже о самостоятельном проектировании объектной структуры. Не всем удается преодолеть барьер освоения этой технологии; многие разработчики, даже работая на объектно-ориентированном языке и применяя объектные библиотеки, фактически используют процедурный стиль программирования.

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

Читайте также: Продажа угля как бизнес

Модуль таблицы (смешанный подход)

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

Типовое решение «модуль таблицы» предусматривает, как и в модели предметной области, отдельные объекты для товаров, заказов и т.д. Однако, в отличие от «настоящей» модели предметной области, в модуле таблицы для работы со всеми (к примеру) заказами, содержащимися в базе данных, применяется только один объект. Именно этот единственный объект содержит логику обработки заказов. А чтобы работать с отдельным заказом, следует указывать его уникальный идентификатор.

Перечитайте предыдущий абзац.

Вас не пугает то, что в нем написано? И вам все понятно? Тогда, скорее всего, для вас не будет иметь значения недостаток данного подхода — сложность разработки и сложность восприятия кода. С точки зрения прозрачности, читабельности кода модуль таблицы заметно проигрывает «настоящей» модели предметной области (конечно, предполагается, что разработчик в каждом случае использует максимум возможностей сделать код простым и понятным). При несложной логике предметной области модуль таблицы проигрывает в простоте реализации и функциональному подходу.

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

Целесообразность применения модуля таблицы также зависит от уровня поддержки структуры множества записей в конкретной среде разработки (включая удобство отображения множества записей на базу данных и на элементы графического интерфейса). Развитая поддержка набора данных ( DataSet ) в среде Microsoft . Net во многих случаях оправдывает применение этой платформы разработки.

Что мы выбираем

Особенности подходов

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

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

Модель предметной области (объектный подход) : наиболее сложный и затратный, позволяет реализовать сложную бизнес-логику, дает возможность «цивилизованно» развивать систему; для простых систем подход целесообразен, только если уже «обкатан» разработчиком.

Модуль таблицы (смешанный подход) : обеспечивает определенное сочетание простоты и гибкости, однако гибкость ограничена, а эффективность подхода зависит от среды разработки.

На основе рассмотренных особенностей можно сформулировать несколько критериев и предложить упрощенную схему выбора подхода на основе качественной оценки критериев.

Качественные критерии и схема выбора

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

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

Схема принятия решения на основе этих критериев приведена на рисунке.

Упрощенная схема выбора типового решения для реализации бизнес-логики

На схеме хорошо видно, что в некоторых случаях выбор сделать очень легко. Например, когда приложение простое, изменений не предвидится, да и с объектной моделью связываться непривычно — с чистой совестью применяем простой функциональный подход. С другой стороны, команда фанатов объектного подхода будет строить объектную модель предметной области во всех случаях — и правильно сделает (учитывая то, что такая команда вряд ли будет заниматься тривиальными проектами).

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

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

В реальных проектах, как обычно, все обстоит сложнее. Например, вопрос организации бизнес-логики может теряться на фоне массы других вопросов разработки архитектуры. Однако это не значит, что решение нужно пускать на самотек. Приведенная схема показывает, что можно предельно упростить принятие решения, не теряя при этом возможность выявить «подводные камни».

Вкратце

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

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

Литература

М. Фаулер. Архитектура корпоративных программных приложений. — М.: Издательский дом «Вильямс», 2006.
Э. Гамма и др. Приемы объектно-ориентированного проектирования. Паттерны

Игорь Остроухов,
6 июля 2006 г.

Источник: www.software-testing.ru