Я слышал много раз, что мы не должны смешивать бизнес-логику с другим кодом или подобных заявлений. Я думаю, что каждый код, который я пишу (я имею в виду шаги обработки), состоит из логики, связанной с бизнес-требованиями..
может ли кто-нибудь сказать мне, что именно состоит из бизнес-логики? Как его можно отличить от другого кода? Есть простой тест, чтобы определить, что бизнес-логика, а что нет?
автор: Rob Cooper
8 ответов
просто определите, что вы делаете на простом английском языке. Когда вы говорите что-то по-деловому, например: «заставьте тех страдать», «украдите эти деньги», «уничтожьте эту часть земли», вы говорите о бизнес-слое. Чтобы прояснить, вещи, которые вас возбуждают, идут сюда.
когда вы говорите «покажите это здесь», «не показывайте это», «сделайте его более красивым», вы говорите о слое презентации. Это то, что возбуждает ваших дизайнеров.
когда вы говорят такие вещи, как» сохранить это»,» получить это из базы данных»,» обновить»,» удалить » и т. д. вы говорите о слое данных. Это вещи, которые говорят вам, что сохранить навсегда любой ценой.
Сергей Мартыненко. Документ спецификации требований к ПО, а нужен ли он?
автор: Serhat Ozgel
вероятно, легче начать с того, что сказать, что не бизнес-логики. Доступ к базе данных или диску-это не бизнес-логика. UI — это не бизнес-логика. Сетевые коммуникации-это не бизнес-логика.
для меня бизнес-логика-это правила, описывающие, как работает бизнес, а не как работает архитектура программного обеспечения. Бизнес-логика также имеет тенденцию меняться. Например, это может быть бизнес-требование, чтобы каждый клиент имел одну кредитную карту, связанную с свой счет. Это требование может измениться, так что клиенты могут иметь несколько кредитных карт. Теоретически это должно быть просто изменение бизнес-логики, и другие части вашего программного обеспечения не будут затронуты.
Это теория. В реальном мире (как вы обнаружили) бизнес-логика имеет тенденцию распространяться по всему программному обеспечению. В приведенном выше примере вам, вероятно, потребуется добавить еще одну таблицу в базу данных для хранения дополнительных данных кредитной карты. Вам обязательно нужно изменить ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС.
пуристы говорят, что бизнес-логика всегда должна быть полностью отдельной и поэтому даже против наличия таблиц с именами «клиенты» или «учетные записи» в базе данных. Доведенный до крайности, вы получите невероятно общую, невозможную для обслуживания систему.
определенно есть сильный аргумент в пользу сохранения большей части вашей бизнес-логики, а не размазывания ее по всей системе, но (как и в большинстве теорий) вам нужно быть прагматичным в реальный мир.
автор: roomaroo
Я думаю, что вы путаете бизнес-логики с вашими требованиями. Это не одно и то же. Когда кто-то объясняет логику своего бизнеса, это что-то вроде:
«когда пользователь покупает товар, то он должен предоставить информацию о доставке. Информация проверяется с помощью правил x y Z. После этого он получит счет-фактуру и заработает очки, что дает х% скидки на y предложений » (извините за плохой пример)
17/48 — Методы выявления требований часть 1. Курс Бизнес-анализ в IT.
когда вы реализуете эти бизнес-правила вам придется подумать о вторичных требованиях, таких как то, как представлена информация, как она будет храниться постоянным способом, связь с серверами приложений, как пользователь получит счет-фактуру и так далее. Все эти требования не являются частью бизнес-логики и должны быть отделены от него. Таким образом, при изменении бизнес-правил вы будете адаптировать свой код с меньшими усилиями. Это факт.
иногда презентация реплицирует некоторую бизнес-логику, в основном при проверке пользовательского ввода. Но она должна присутствовать и на уровне бизнес-логики. В других ситуациях необходимо переместить некоторую бизнес-логику в базу данных, для проблем с производительностью. Это обсуждает Мартин Фаулер здесь.
автор: Marcio Aguiar
все упростить до одной строки.
Бизнес-логика — это код, который не зависит от/не будет меняться с определенной деталью пользовательского интерфейса/реализации.. Это кодовое представление правил, процессов и т. д. которые определяются / отражают моделируемый бизнес.
автор: Gishu
Мне не нравятся имена bll+DAL слоев, они более запутанные, чем уточняющие.
Назовите это DataServices и DataPersistence. Так будет проще.
сервисы манипулируют, персистентность уровня CRUDs (Create, Read, Update, Delete)
автор: Lars Mæhlum
для меня, » бизнес-логики » составляют все сущности, представляющие данные, применимые к проблемной области, а также логику, которая решает «что делать с данными»..
поэтому он должен действительно состоять из «передачи данных» (не доступа) и «обработки данных».. На самом деле доступ к данным (материал, попадающий в БД) должен быть на другом уровне, как и код презентации.
автор: Rob Cooper
Если она содержит что-либо о таких вещах, как форма, кнопка и т. д.. это не бизнес-логика, это уровень презентации. Если он содержит сохраняемость файла или базы данных, это DAL. Все, что между ними, — это бизнес-логика. На самом деле все, что не является UI, иногда называют «бизнес-логикой», но это должно быть что-то, что касается проблемной области, а не ведения дома.
автор: Eugene Yokota
бизнес-логика-это чистая абстракция, она существует независимо от материализации/визуализации данных перед вашим пользователем и независимо от сохранения базовых данных.
например, в программном обеспечении для подготовки налогов одной из обязанностей классов бизнес-логики было бы вычисление задолженности по налогам. Они не будут нести ответственность за отображение отчетов или сохранение и получение налоговой декларации.
Источник: askdev.ru
Для реферата / Radchenko_Distributed_Computer_Systems
ности посредством старого API (например, получение словарных статей) или же не менять используемый интерфейс до тех пор, пока не потребуется использование новых возможностей. − Рекурсивность . Однотипные решения имеют место на различных уровнях архитектуры. 8.4 Подход СОА С точки зрения информационных технологий, логика предприятия может быть разделена на две важных половины: бизнес-логика и логика приложения (рис.
23). Каждый слой существует в своем собственном «мире». Рис. 23. Уровни логики предприятия Бизнес — логика является документальной реализацией бизнес-требований, которые исходят из проблемной области, в которой работает предприятие. Биз- нес-логика, как правило, структурирована в процессах, которые выражают эти требования, а также ограничениях и зависимости от внешних влияний.
Логика приложения – это реализация бизнес-логики, организованная на основе различных технологических решений. Логика приложения выражает процессы бизнес-логики посредством приобретенных или специально разрабо- танных программных систем в условиях ограниченных технических возможностей и зависимостей от поставщика решения. 85
Процесс преобразования бизнес-логики в логику приложений и реализация сервисов на основе данных требований является процессом создания сервисноориентированной инфраструктуры для задач предприятия. Не существует «догматических» принципов построения СОА, но при реализации собственной инфраструктуры желательно придерживаться некоторых основных подходов, описанных ниже.
1. Сервисы должны поддерживать повторное использование . СОА- системы должны поддерживать повторное использование всех сервисов, неза- висимо от сиюминутных требований к их функциональным особенностям. Если при разработке системы постараться максимально учесть это требование, то повышаются шансы значительно упростить процесс решения задач, которые непременно появятся в будущем, при развитии системы.
Также изначально ориентированный на повторное использование сервис позволяет избежать разработки «обертки», которая бы подстраивала старый сервис для решения новых задач. Так как сервис – это не что иное, как просто набор связных операций, ло- гика каждой индивидуальной операции, предоставляемой сервисом, должна поддерживать повторное использование.
Например, в компании А-comp для отправки счета в систему биллинга «B- comp Account Payable Service» используется метод SubmitInvoice . Для того чтобы проверить состояние счета, необходимо постоянно проверять метадан- ные отправленного счета. Для этого используется метод GetBcompMetadata . Т.к. эти операции ориентированы на решение сиюминутных , и вполне кон- кретных задач, они не имеют потенциала повторного использования . Метод SubmitInvoice разработан таким образом, чтобы транслировать сообщение в специфичном XML-формате, соответствующем системе B-comp, то есть «заточен» на конкретную версию протокола обмена информацией и конкретные данные. Метод GetBcompMetadata (как мы можем понять из имени метода) из- начально ориентирован на использование исключительно с компанией B-comp, и не допускает повторного использования с любой другой системой биллинге. Если бы компания A-comp задумалась о правильной сервисно- ориентированной инфраструктуре, то были бы разработан универсальный ин- терфейс с методами типа « SubmitInvoice » и « CheckInvoice », реализацию кото- рых можно было бы использовать для любой внешней системы биллинга. 86
Сервис-ориентированная архитектура
2. Сервисы должны обеспечивать формальный контракт использования . Контракт сервиса предоставляет следующую информацию: − конечную точку (service endpoint): адрес, по которому можно обратиться к данному сервису; − все операции, предоставляемые сервисом; − все сообщения, поддерживаемые каждой операцией; − правила и характеристики сервиса и его операций. 3. Сервисы должны быть слабосвязаны . Никто не может предугадать, в какую сторону будет развиваться IT-инфраструктура.
Решения могут разви- ваться, взаимодействовать, заменять друг друга. В связи с этим основной задачей является сохранение целостности системы в рамках такого развития, неза- висимо от происходящих изменений. Система сервисов является слабосвязанной, если сервис может приобре- тать знания о другом сервисе, оставаясь независимым от внутренней реализации логики данного сервиса.
Это достигается посредством использования кон- трактов сервисов. Слабосвязанность программных компонентов, лежащая в основе СОА, позволяет значительно упростить координацию распределенных систем и их реконфигурацию. Основная цель использования концепции слабосвязанных программных систем – это уменьшение количества зависимостей между компонентами.
При уменьшении количества связей, уменьшается объем возмож- ных последствий, возникающих в связи со сбоями или системными изменениями. Слабосвязанность – это не синоним «инкапсуляции» объектноориентированной концепции построения программных систем.
Программная система может полностью соответствовать требованиям инкапсуляции, но быть сильносвязанной на семантическом уровне. Например, существует сервис, который должен передавать большой объем текстовой информации в открытом виде другому сервису. При этом символ но- вой строки передавать нельзя, так как это неадекватно обрабатывается XMLпарсером, и вся информация после знака новой строки теряется. Что же делать в этом случае? Первое решение, которое приходит в голову разработчику – это замена всех вхождений символов переноса строки на любой другой редко встречающийся в передаваемых сообщениях символ (или последовательность символов). В этом случае единственная деталь, которую необходимо учесть – 87
это описать в приемнике простейшую обратную процедуру, которая будет де- лать обратную замену, и вопрос решен. Поступая так, разработчик игнорирует принцип слабосвязанности программных систем, так как в этом случае клиент и сервер будут взаимодействовать между собой не на основе открытого ин — терфейса , а на основе информации о внутренних процессах работы друг друга . Разработчик не задумывается о последствиях, которые может повлечь за собой в дальнейшем такое решение.
Если через несколько месяцев (когда этот «финт» забудется) сторонний разработчик захочет создать собственного клиента для данного сервиса он будет неприятно удивлен, увидев вместо ожидаемого форматированного текста странные символы. Еще большая проблема возникнет, если вдруг в самом тексте будет появляться последовательность символов, на которую разработчик заменил символ новой строки.
Поддержка такой системы превратится в постоянную пытку. Существует несколько вариантов решения данной задачи посредством перехода к концепции слабосвязанных систем. Одним из оптимальных решений является переход от передачи данных в виде строки к передаче данных в виде массива строк.
Это будет явно отражено в интерфейсе системы, соответствен- но, любой клиент будет знать, что данные к нему будут переданы в виде массива строк, каждая из которых заканчивается символом перехода на новую стро- ку. 4. Сервисы должны абстрагировать внутреннюю логику . Каждый сервис должен действовать как «черный ящик», скрывающий свои детали от окружа- ющего мира.
Нет четкого определения, какой объем логики должен помещаться в отдельном сервисе. Взаимодействие на уровне интерфейсов является одним из требований для обеспечения слабой связанности. 5. Сервисы должны быть совместимы . Сервис может как самостоятельно реализовывать логику, так и применять другие сервисы для ее реализации. Сер- висы должны быть спроектированы таким образом, чтобы поддерживать возможность их использования в качестве элементов другого сервиса. Принцип совместимости не зависит от того, использует ли сервис для выполнения своей работы другие сервисы. 88
Сервис-ориентированная архитектура
Рис. 24. Сервисы, используемые в качестве элементов другого сервиса В качестве примера такого взаимодействия сервисов выступает концепция оркестрации сервисов.
В этом случае, сервис-ориентированный процесс (кото- рый в принципе может быть определен как композиция сервисов) управляется сервисом родительского процесса, который включает в себя другие сервисы, являющиеся участниками данного процесса. Кроме того, принцип совместимости также определяет вид сервисных опе- раций.
Совместимость – это, по сути, просто другая форма повторного использования, и поэтому операции должны быть стандартными, а для наибольшей совместимости должны обладать необходимым уровнем детализации. 6. Сервисы должны быть автономными . Свойство автономности требует, чтобы область бизнес-логики и ресурсов, используемых сервисом были ограни- чены явными пределами.
Это позволяет сервису самому управлять всеми своими процессами (рис. 25). Также это устраняет зависимость от других сервисов, что освобождает сервис от связей, которые могут препятствовать его применению и развитию. Вопрос автономности – наиболее важный аргумент при рас- пределении бизнес-логики на отдельные сервисы.
Обратите внимание, что автономность не обязательно предоставляет сер- вису исключительное право собственности на бизнес-логику, которую он инкапсулирует. Есть только гарантия того, что во время исполнения сервис кон- тролирует любую логику, которую он реализует. Поэтому мы можем выделить два типами автономности. 89
Рис. 25. Автономность сервиса: во время выполнения сервис управляет логикой нижнего уровня − Автономность на уровне сервиса : границы ответственности сервисов от- делены, но они могут использовать общие ресурсы.
Например, сервис обертки, который инкапсулирует унаследованную программную систему, которая также кем-то используется (независимо от данного сервиса), обла- дает автономностью данного типа. Он управляет унаследованной системой, но также совместно использует ресурсы с другими существующими клиентами. − Чистая автономность : бизнес-логика и ресурсы находятся под полным контролем сервиса.
Как правило, такой вид автономности используется, когда для реализации сервиса бизнес-логика создается с нуля. 7. Сервисы не должны использовать информацию о состоянии . Сервисы должны сводить к минимуму объем информации о состоянии, и время, в течение которого они ею обладают. Информация о состоянии – это определенные данные, характеризующие текущую деятельность.
Например, пока сервис обрабатывает сообщение, он временно зависит от состояния (stateful). Если сервис несет ответственность за сохранение состояния в течение более длительного времени, его способность оставаться доступным для других клиентов будет за- труднена. Независимость от состояния (statelessness) позволяет повысить возможно- сти масштабируемости и повторного использования сервисов. Чтобы сервис 90
Сервис-ориентированная архитектура
как можно меньше зависел от состояния, его операции должны быть разработа- ны с учетом соображений обработки информации без данных о состоянии. Основной особенностью СОА, поддерживающей независимость от состоя- ния, является использование сообщений-документов. Чем выше сложность сообщения, тем более независимым и самодостаточным оно остается. Рис. 26.
Временная зависимость от состояния во время обработки сообщения 8. Сервисы должны поддерживать обнаружение . Обнаружение сервисов позволяет избежать случайного создания избыточного сервиса, обеспечиваю- щего избыточную логику. Метаданные сервиса должны подробно описать не только общую цель сервиса, но и функциональность, реализуемую его опера- циями. На уровне СОА, обнаружение характеризует способность архитектуры обеспечить механизмы поиска, такие как реестр или каталог. На уровне сервиса, принцип обнаружения относится к процессу проектирования отдельного сервиса, так чтобы данный сервис настолько подавался обнаружению, насколько это возможно. Рассмотрим пример. Компания RailCo не обеспечивает никаких средств обнаружения своих сервисов, как внутри своей компании, так и для внешних 91
пользователей. Хотя каждый сервис и обладает собственным WSDL- документом и в полной мере способен выступать в качестве поставщика услуг, сервис подачи счета в первую очередь используется в качестве элемента друго- го сервиса и не ожидает никаких сообщений от других сервисов, кроме сервиса оплаты счетов.
Сервис выполнения заказа (RailCo) был вручную зарегистрирован с помощью B2B-решения компании TLS, так что он будет помещен в список доступ- ных сервисов. Этот сервис не предоставляет функциональность многоразового использования, и поэтому считается, что он не обладает способностью к обна- ружению. Рис. 27.
Обнаружение на уровне логики предприятия Из-за многоразового характера использования сервисов компании TLS и из-за количества сервисов, которые, как ожидалось, будут реализованы в компании TLS, был создан реестр внутренних сервисов (рис. 27). Эта часть инфра- структуры TLS способствует обнаружению сервисов и предотвращению случайной избыточности. 92
9. Веб-сервисы 9.1 Веб-сервисы первого поколения XML Веб — сервисы ( Веб — службы ) – это программные компоненты, с помощью которых можно создавать независимые масштабируемые слабосвязанные приложения. В основе технологии веб-сервисов лежит процесс обмена сообщениями в формате XML-документов. Передача сообщений происходит с использованием протоколов HTTP, XML, XSD, SOAP, WSDL, UDDI.
Спецификация определяет три основных стандарта, используемых для поддержки представления, поиска и обмена информацией между веб-сервисами – это WSDL, UDDI и SOAP, образующие так называемый «треугольник СОА». Процесс взаимодействия между клиентом и поставщиком веб-сервиса пред- ставлен на рисунке 28. Рис. 28.
Процесс взаимодействия между клиентом и поставщиком веб-сервиса Протокол SOAP ( уже не «Simple Object Access Protocol», см . ниже ) пред- назначен для организации взаимодействия удаленных систем при помощи асинхронного обмена XML-отформатированными документами, состоящими из трех частей: конверта (обертки), заголовка и тела. SOAP формирует базовый слой стека протоколов веб-сервисов, обеспечивая инфраструктуру обмена сообщениями между ними. Хотя изначально название протокола SOAP и рас- шифровывалось как «Простой Протокол Доступа к Объектам» («Simple Object Access Protocol»), в версии 1.2 стандарта от этого определения отошли, и теперь этот акроним ничего не означает. Язык WSDL (Web Services Description Language) описывает сервисы в виде неких абстрактных ресурсов, способных принимать на вход документы определенных типов и инициировать отправление документов других типов. WSDL 93
используется для описания веб-сервисов и для определения их расположения. WSDL написан на XML и является XML-документом. WSDL определяет сервис с двух точек зрения: абстрактной и конкретной . На абстрактном уровне сервис задается в терминах посылаемых и принимаемых им сообщений, которые описываются средствами XML Schema в виде, не- зависимом от конкретного транспортного протокола.
На конкретном уровне определяются привязки к транспортным форматам и точкам физического раз- мещения. Группа спецификаций WSDL 2.0 состоит из трех основных документов – WSDL Part 1: Core language («Основной язык»), WSDL Part 2: Message exchange patterns («Шаблоны обмена сообщениями»), WSDL Part 2: Bindings («Привяз- ки»).
Протокол UDDI (Universal Description Discovery https://studfile.net/preview/1175920/page:9/» target=»_blank»]studfile.net[/mask_link]
Что именно состоит из «бизнес-логики» в приложении?
Я неоднократно слышал, что мы «не должны смешивать бизнес-логику с другим кодом» или подобные заявления. Я думаю, что каждый код, который я пишу (я имею в виду этапы обработки), состоит из логики, которая связана с требованиями бизнеса.
Может кто-нибудь сказать мне, что именно состоит из бизнес-логики? Как это можно отличить от другого кода? Есть ли простой тест, чтобы определить, что такое бизнес-логика, а что нет?
user184 02 сен ’08 в 11:40 2008-09-02 11:40
2008-09-02 11:40
8 ответов
Просто определите, что вы делаете на простом английском языке. Когда вы говорите что-то деловое, например, «заставить тех страдать», «украсть эти деньги», «уничтожить эту часть земли», вы говорите о бизнес-уровне. Чтобы было понятно, вещи, которые вас взволновали, идут сюда.
Когда вы говорите «покажите это здесь», «не показывайте этого», «сделайте его красивее», вы говорите о уровне представления. Это то, что вдохновляет ваших дизайнеров.
Когда вы говорите такие вещи, как «сохранить это», «получить это из базы данных», «обновить», «удалить» и т. Д., Вы говорите о слое данных. Это вещи, которые говорят вам, что сохранить навсегда любой ценой.
user31505 02 сен ’08 в 11:43 2008-09-02 11:43
2008-09-02 11:43
Вероятно, проще начать с того, что не бизнес-логика. Доступ к базе данных или диску не является бизнес-логикой. Интерфейс не бизнес-логика. Сетевые коммуникации не являются бизнес-логикой.
Для меня бизнес-логика — это правила, которые описывают, как работает бизнес, а не как работает программная архитектура. Бизнес-логика также имеет тенденцию меняться. Например, это может быть деловое требование, чтобы каждый клиент имел одну кредитную карту, связанную с его учетной записью. Это требование может измениться, чтобы клиенты могли иметь несколько кредитных карт. Теоретически, это должно быть просто изменение бизнес-логики, и другие части вашего программного обеспечения не будут затронуты.
Так что это теория. В реальном мире (как вы обнаружили) бизнес-логика имеет тенденцию распространяться по всему программному обеспечению. В приведенном выше примере вам, вероятно, потребуется добавить еще одну таблицу в базу данных для хранения дополнительных данных кредитной карты. Вам, безусловно, нужно изменить пользовательский интерфейс.
Пуристы говорят, что бизнес-логика всегда должна быть полностью отдельной, и это даже противоречит наличию в базе данных таблиц с именами «Клиенты» или «Счета». Взяв его до крайности, вы получите невероятно универсальную, не обслуживаемую систему.
Есть определенно веский аргумент в пользу сохранения большей части вашей бизнес-логики, а не размазывания ее по всей системе, но (как и в большинстве теорий) вы должны быть прагматичными в реальном мире.
Источник: stackru.com
