Бизнес-логика — это совокупность правил, принципов и зависимостей поведения объектов предметной области [81. Также часто используется синоним этого понятия логика предметной области (анг. domain logic).
К уровню бизнес-логики относится реализация предметной области в информационной системе. Примерами элементов бизнес- логики являются экономические показатели эффективности производства, методы управления кадрами, методы управления предприятием, стратегии биржевой торговли и др.
Уровень данных
К уровню данных относят программы, которые обеспечивают предоставление данных для приложений. Уровень данных может быть реализован:
- • средствами файловой системы (в простейшем случае);
- • путём использования базы данных.
Уровень данных, как правило, располагается на стороне сервера. Основными требованиями к этому уровню являются:
- • сохранность данных — даже при неработающем приложении данные должны храниться в заданном месте в расчете на последующее использование;
- • поддержание целостности данных — обеспечение корректности данных и их непротиворечивости (включает целостность связей, чтобы исключить ошибки связей между первичным и вторичным ключом).
Данные могут быть организованы в форме реляционной базы данных, либо в форме объектно-ориентированной базы данных.
#8 Бизнес логика или детали реализации? — Vue.js: концепции
Использование реляционных баз данных позволяет отделить уровень обработки от уровня данных. При этом обеспечивается независимость данных от приложений: изменения в организации данных не оказывают влияния на приложения, а приложения никак не влияют на организацию данных.
Объектно-ориентированные базы данных целесообразно использовать в случаях, когда данные и операции над ними проще описываются с помощью объектов, а не отношений. При этом обеспечивается хранение сложно организованных данных в форме объектов, и хранение методов обработки этих объектов. В связи с этим некоторая часть функций с уровня обработки переходит на уровень данных. Примерами использования объектов являются проекты интегральных микросхем, автомобиля, самолёта и т.д.
Источник: studme.org
Доменные объекты / сервисы и уровень бизнес-логики
Что такое объекты домена и службы домена в архитектуре программного обеспечения? Я не знаком с ними или как они отличаются от уровня бизнес-логики?
aces. 08 апр. 2011, в 03:08
Поделиться
Поделиться:
business-logic-layer
domain-object
4 ответа
Лучший ответ
Различные люди используют эти термины несколькими способами, но здесь я беру: 1) «Бизнес» и «домен» являются примерно синонимами. «Домен» немного более общий, поскольку он не делает предположение, что вы пишете бизнес-приложение. Поэтому, если мы пишем научное приложение или игру, мы можем предпочесть ссылаться на соответствующую часть кода как на код домена, а не на код «бизнес».
Архитектура ПО, MVC и бизнес-логика. Критика Django
Поэтому в оставшейся части этого объяснения я буду использовать «домен», поскольку он более общий. 2) «Логика домена» понимает как «объекты домена», так и «службы домена».
По различным причинам (техническим и иным) многие архитектуры используют дизайн, в котором логика домена разделена на объекты для хранения данных ( «объекты домена» ) и объекты, которые ими управляют ( «службы домена» ). Мартин Фаулер и другие отметили, что это не очень OO, поскольку большая часть концепции OO заключается в том, чтобы добавить функциональность вместе с данными, и это право, Но что есть, то есть. Объектами домена являются данные и службы домена — это часть do-stuff-with-the-data. 3) В доменном дизайне идея состоит в том, чтобы вернуться к истинному дизайну OO, и поэтому различные методы обслуживания возвращаются к объектам домена, так что у вас есть объекты в смысле ОО, а не то, что иногда называемых «анемичными» объектами. В DDD объекты домена сами по себе более надежны и поэтому образуют логику домена. На самом деле все еще могут быть некоторые службы домена, но это обычно меньше в DDD, чем в более традиционной модели объектов объектов и услуг.
Willie Wheeler 08 апр. 2011, в 03:37
Поделиться
Хорошее начало понимания, спасибо!
Jerome Dalbert 08 июль 2012, в 23:57
Jo Smo 11 сен. 2014, в 15:28
Перечитайте № 2 и № 3 выше. Анемичные бизнес-объекты проще в реализации, но, возможно, меньше в ОО-духе.
Willie Wheeler 11 сен. 2014, в 15:39
Wax 23 авг. 2016, в 13:08
Willie Wheeler 23 авг.
2016, в 16:03
Насчет # 2, удивительно произвольный код, который люди придумывают только потому, что решили.
magallanes 05 нояб. 2017, в 13:32
Я бы сказал, что определение предметного объекта не должно касаться объектов, хранящих данные. «Объекты» в мире ООП содержат как данные, так и поведение. На самом деле, Уорд Каннингем перечисляет «поддерживать бизнес-логику» как одну из особенностей объекта предметной области. wiki.c2.com/?DomainObject . Я понимаю, что вы иллюстрируете, что именно так «многие архитектуры» используют объект домена, но просто хотели уточнить, что это не стандартное определение (и не рекомендуемое использование, как вы указали).
THIS USER NEEDS HELP 13 авг. 2018, в 22:29
Willie Wheeler 26 фев. 2019, в 02:50
Показать ещё 6 комментариев
Уровень бизнес-логики также называется уровнем домена. Это уровень/уровень, который обрабатывает всю бизнес-логику.
Объекты домена и доменные службы — это классы, которые вы используете для создания своего домена.
Jørn E. Angeltveit 08 апр. 2011, в 01:39
Поделиться
Я думал, что уровень бизнес-логики и уровень домена отличаются. Я читал лучшие практики Java от Oreilly и натолкнулся на следующую строчку: If your application naturally separates into standard layers (persistence, domain objects, business logic, presentation), you should consider using EJBs. Так в чем же разница между доменом / бизнес-логикой?
aces. 08 апр. 2011, в 00:45
Это зависит от того, сколько слоев вы выберете в своем приложении. У вас может быть только двухуровневое приложение, и у вас может быть до шести или семи разных слоев.
Jørn E. Angeltveit 08 апр. 2011, в 00:49
логика домена = бизнес логика
Jørn E. Angeltveit 08 апр. 2011, в 00:53
Извините, если это неопределенный вопрос. Но у меня возникают проблемы с пониманием концепции доменных объектов и концепции, управляемой доменом. Согласовано. Если мы рассмотрим сценарий построения 4-уровневого программного приложения с отдельными слоями для представления, бизнеса, предметного объекта, бизнес-логики и постоянства.
Как мне решить, что формирует предметную и бизнес-логику? Что такое доменные объекты? А что такое доменный дизайн?
aces. 08 апр. 2011, в 00:55
DDD — это подход, который используется, когда домен сложный. If фокусируется на основной предметной логике и процессе, который устанавливает сложную бизнес-модель (т. Е. Сотрудничество между программистами и экспертами в предметной области). Доменная логика относится к общим бизнес-правилам, а доменные объекты представляют различные реальные бизнес-объекты (человек, кредит, инвесторы), которые участвуют в этой доменной логике.
Jørn E. Angeltveit 08 апр. 2011, в 01:08
Nikhil Vartak 08 июнь 2017, в 21:34
Jørn E. Angeltveit 08 июнь 2017, в 22:01
Показать ещё 5 комментариев
Нам нужно понять обязанности уровня приложения и уровня домена (бизнеса), чтобы иметь возможность понять разницу. Доменный уровень представляет бизнес-объекты, главным образом сущности из бизнеса, возможно, в некоторой степени абстрагированные и службы домена. Уровень домена изменяется только при изменении бизнеса или изменении контекста домена в бизнесе. Уровень приложения «живет» поверх уровня домена и часто (предпочтительно) отделен от уровня домена, например, с помощью веб-приложения asp.net MVC, где частью контроллера является прикладной уровень, а часть HTML является уровнем представления. Уровень приложения изменяется в соответствии с назначением этого конкретного приложения (или службы, API, приложения и т.д.).
Andreas R. Munch 06 нояб. 2014, в 10:14
Поделиться
Позвольте мне предложить этот пример сценария корпоративного приложения, с которым я работал, чтобы объяснить, почему уровень домена и бизнес-уровень содержат бизнес-логику, но разные.
Предположим, что у меня есть продукт COTS, который является чистым механизмом управления случаями, скажем, реализация OMG CMMN. Целая группа бизнес-логики в бизнес-уровне, которая работает с кучей сущностей из уровня данных.
Теперь продолжайте полагать, что у меня есть два клиента, которые являются системными интеграторами, один из них строит систему управления судебными делами и хочет, чтобы управление случаями лечения. оба — управление случаями, но имеют свои собственные термины, объекты, процедуры, отраслевые архитектуры и т.д.
Каждый будет добавлять свой собственный уровень домена, чтобы они могли работать в терминах и понятиях соответствующего бизнес-домена.
Итак, да, в нем содержится бизнес-логика, но уровень домена — это способ инкапсуляции общего многоразового бизнеса с конкретным бизнесом.
«Более простое» приложение более похоже на модель домена и модель данных, а также бизнес-логику и логику домена. Но когда вы увеличиваете «полезность» компонента, расходятся, в конце концов проблемы разделяются.
Источник: overcoder.net
Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы
10 : 48 , 10 мая 2021 г.
Затем появились первые фреймворки, работать с ними стало удобнее, но они не учили, как правильно заложить структуру, архитектуру проекта. И разработчики продолжали писать тысячи строк кода в контроллерах новомодных фреймворков.
1. Выход есть
Как известно, Vue.js, React.js и прочие подобные фреймворки основаны на компонентах. То есть, по большому счету, приложение состоит из множества компонентов, которые могут заключать в себе и бизнес-логику и представление и много чего еще.
Таким образом, разработчики во многих проектах пишут всю логику в компонентах и эти компоненты, как правило, начинают напоминать те самые божественные классы из прошлого. То есть, если компонент описывает какую-то крупную часть функционала с большим количеством (возможно сложной) логики, то вся эта логика и остается в компоненте. Появляются десятки методов и тысячи строк кода. А если учесть то, что, например, во Vue.js еще есть такие понятия как computed, watch, mounted, created, то логику пишут еще и во все эти части компонента. В итоге, чтобы найти какую-то часть кода, отвечающую за клик по кнопке, надо перелистать десяток экранов js-кода, бегая между methods, computed и прочими частями компонента.
Примерно в 2008 году, применительно к backend, была предложена “слоистая” архитектура. Основная идея этой архитектуры заключается в том, что весь код приложения следует разбивать на определенные слои, которые выполняют определенную работу и не очень знают о других слоях.
С подобным разбиением приложение становится намного проще поддерживать, писать тесты, искать ответственные зоны и вообще читать код.
Вот о таком разбиении кода на слои и пойдет речь, но уже применительно к frontend-фреймворкам, таким как Vue.js, React.js и прочим.
Изначальная теория “слоистой” архитектуры, применительно к backend, имеет много ограничений и правил. Идея же этой статьи в том, чтобы перенять именно разбиение кодовой базы на слои. Схематично ее можно изобразить примерно так.
2. Создание удобной архитектуры приложения
Рассмотрим пример, в котором вся логика находится в одном компоненте.
2.1. Логика в компоненте
Рассматриваемый компонент отвечает за работу с коллажами, в частности за дублирование, восстановление и удаление. В нем уже используются некоторые сервисы, но все равно в компоненте много бизнес-логики.
2.2. Создание слоя сервисов для бизнес-логики
Для начала можно ввести в приложение сервисный слой, который будет отвечать за бизнес-логику.
Один из классических способов хоть какого-то разбиения логики – это деление на сущности. Например, почти всегда в проекте есть сущность Пользователь или, как в описываемом примере, Коллаж. Таким образом, можно создать папку services и в ней – файлы user.js и collage.js. Такие файлы могут быть статическими классами или просто возвращать функции. Главное – чтобы вся бизнес-логика, связанная с сущностью, была в этом файле.
В сервис collage.js следует поместить логику дублирования, восстановления и удаления коллажей.
2.3. Использование сервисов в компоненте
Тогда в компоненте надо будет лишь вызвать соответствующие функции сервиса.
С таким подходом методы в компоненте будут состоять из одной или нескольких строчек кода, а логика, связанная с коллажами, будет инкапсулирована в соответствующем файле collage.js, а не размазана по огромному компоненту, соответственно, будет проще искать нужный код, поддерживать его и писать тесты. Еще один плюс такого подхода в том, что код из сервисов можно переиспользовать в любом месте проекта.
Также многие разработчики на пути к удобной архитектуре выносят вызовы методов API в отдельный файл (файлы). Это как раз создание слоя вызовов API, которое также приводит к удобству и структурированности кода.
3. Что и куда выносить?
На вопрос, что же именно и куда выносить, однозначно ответить невозможно. Как вариант, можно разбить код на три условные части: бизнес-логика, логика и представление.
Бизнес-логика – это все то, что описано в требованиях к приложению. Например, ТЗ, документации, дизайны. То есть все то, что напрямую относится к предметной области приложения. Примером может быть метод UserService.login() или ListService.sort(). Для бизнес-логики можно создать сервисный слой с сервисами.
Логика – это тот код, который не имеет прямого отношения к предметной области приложения и его бизнес-логике. Например, создание уникальной строки или поиск некоего объекта в массиве. Для логики можно создать слой хэлперов: например, папку helpers и в ней файлы string.js, converter.js и прочие.
Представление – все то, что непосредственно связано с компонентом и его шаблоном. Например, изменение реактивных свойств, изменение состояний и прочее. Этот код пишется непосредственно в компонентах (methods, computed, watch и так далее).
Далее в компонентах надо будет вызывать сервисы, а сервисы будут использовать хэлперы. Такой подход предоставит нам легкие, маленькие и простые компоненты, а вся логика будет находиться в логически понятных файлах.
Если же сервисы или хэлперы начнут разрастаться, то сущности всегда можно разделить на другие сущности. К примеру, если у пользователя в приложении маленький функционал в 3-5 методов и пара методов про заказы пользователя, то разработчик может вынести всю эту бизнес-логику в сервис user.js. Если же у сервиса пользователя сотни строк кода, то можно все, что относится к заказам, вынести в сервис order.js.
4. От простого к сложному
В идеале можно сделать архитектуру на ООП, в которой будут, помимо сервисов, еще и модели. Это классы, описывающие сущности приложения. Те же User или Collage. Но использоваться они будут вместо обычных объектов данных.
Рассмотрим список пользователей.
Классический способ вывода ФИО пользователей выглядит так.
Функцию получения ФИО можно вынести для того, чтобы легко и просто переиспользовать при необходимости.
Для начала следует создать модель Пользователь.
Далее следует импортировать эту модель в компонент.
С помощью сервиса получить список пользователей и преобразовать каждый объект в массиве в объект класса (модели) User.
Таким, образом, в шаблоне или в методах не надо будет создавать какие-то отдельные функции для работы с объектом пользователя, они будут уже внутри этого объекта.
К вопросу о том, какую логику выносить в модели, а какую в сервисы. Можно всю логику поместить в сервисы, а в моделях вызывать сервисы. А можно в моделях хранить логику, относящуюся непосредственно к сущности модели (тот же getFio()), а логику работы с массивами сущностей хранить в сервисах (тот же getList()). Как будет удобнее.
5. Заключение
Если в проекте большое количество логики хранится в компонентах, есть риск сделать их трудночитаемыми и осложнить дальнейшее переиспользование логики. В таких случаях можно ввести “слои” для вынесения этой логики: например, слой сервисов для бизнес-логики, слой хэлперов для остальной логики. Внутри компонента стоит оставить ту логику, которая относится непосредственно к нему и его шаблону.
Также для удобства можно создать слои для операций с сессиями, перехватчиками (interceptors) api, глобальными обработчиками ошибок – смотря что вам будет удобно. Таким образом, вы сделаете компоненты маленькими и простыми, а логика будет храниться там, где ее легко будет найти и переиспользовать в любом месте проекта.
Источник: news.myseldon.com
