#java #business-logic-layer #domain-object
#java #уровень бизнес-логики #домен-объект
Вопрос:
Что такое объекты домена и доменные службы в архитектуре программного обеспечения? Я не знаком с ними или чем они отличаются от уровня бизнес-логики?
Ответ №1:
Разные люди используют эти термины несколько по-разному, но вот мое мнение:
1) «Бизнес» и «домен» — это примерно синонимы. «Домен» немного более общий в том смысле, что он не предполагает, что вы пишете бизнес-приложение. Итак, если бы мы писали научное приложение или игру, мы могли бы предпочесть ссылаться на соответствующую часть кода как на код «домена», а не как на «бизнес» код. Итак, в оставшейся части этого объяснения я буду использовать «домен», поскольку оно более общее.
2) «Логика домена» включает в себя как «объекты домена», так и «службы домена». По различным причинам (техническим и иным) во многих архитектурах используется дизайн, в котором логика домена разделена на объекты для хранения данных («объекты домена») и объекты, которые управляют ими («службы домена»). Мартин Фаулер и другие отметили, что это не очень OO, поскольку большая часть концепции OO заключается в объединении функциональности с данными, и это правильно, но так оно и есть. Объекты домена — это данные, а службы домена — это часть, предназначенная для работы с данными.
3) При проектировании, управляемом доменом, идея состоит в том, чтобы вернуться к истинному дизайну OO, и поэтому различные методы обслуживания возвращаются к объектам домена, чтобы у вас были объекты в смысле OO, а не то, что иногда называют «анемичными» объектами. В DDD сами объекты домена более надежны, и поэтому они формируют логику домена. В действительности все еще могут существовать некоторые доменные службы, но в DDD их обычно меньше, чем в более традиционной модели «доменные объекты против служб».
Комментарии:
1. @Willie Wheeler что должно входить в объект домена, а что — в службы домена? Я новичок в mvc.
2. Перечитайте # 2 и # 3 выше. Анемичные бизнес-объекты проще реализовать, но, возможно, менее соответствуют духу OO.
3. @WillieWheeler Эй, чувак, я новичок в Java и пытаюсь научиться правильно создавать объекты beans / java domain. Давайте предположим, что у меня есть dragon, и у него может быть несколько классов (ролей). (например, dragon может быть отслеживающим, в то же время он может быть нападающим.). Я планирую отобразить классы dragon на своей домашней странице, когда вы нажимаете на класс, он показывает вам список dragon в этом классе, но по какой-то причине мне очень сложно придумать структуру, как это сделать правильно
4. @Carnal Полезный ответ не поместится в комментарии. Я предлагаю создать актуальный вопрос для этого по адресу programmers.stackexchange.com .
5. Что касается # 2, то удивительно, что произвольный код, который люди изобретают только потому, что они так решили.
Ответ №2:
Уровень бизнес-логики также называется уровнем домена. Это уровень, который обрабатывает всю бизнес-логику.
Доменные объекты и доменные службы — это классы, которые вы используете для построения своего доменного уровня.
Комментарии:
1. Я думал, что уровень бизнес-логики и уровень домена отличаются. Я читал лучшие практики Java от Oreilly и наткнулся на эту строку :
If your application naturally separates into standard layers (persistence, domain objects, business logic, presentation), you should consider using EJBs.Итак, в чем разница между доменом / бизнес-логикой?2. Это зависит от того, сколько уровней вы решите создать в своем приложении. У вас может быть только двухуровневое приложение, и у вас может быть целых шесть или семь разных уровней.
3. логика домена = бизнес-логика
4. DDD — это подход, который следует использовать, когда домен сложный. If фокусируется на логике основного домена и процессе, который устанавливает сложную бизнес-модель (т.е. сотрудничество между программистами и экспертами в предметной области). Логика домена ссылается на общие бизнес-правила, а объекты домена представляют различные бизнес-объекты реальной жизни (person, loan, investors), которые задействованы в этой логике домена.
5. @niks: достаточно справедливо. Я большой поклонник точности в терминах, но, на самом деле, предложение все еще имеет смысл — даже если вы помните об этом различии?
Ответ №3:
Нам нужно понимать обязанности прикладного уровня и доменного (бизнес) уровня, чтобы быть в состоянии уловить разницу. Уровень домена представляет бизнес-объекты, в основном сущности из бизнеса, возможно, в некоторой степени абстрагированные, и доменные службы. Уровень домена изменяется только при изменении бизнеса или контекста домена внутри бизнеса. Уровень приложений «живет» поверх уровня домена и часто (предпочтительно) отделен от уровня домена, например, с помощью asp.net Веб-приложение MVC, где часть контроллера является прикладным уровнем, а часть HTML — уровнем представления. Уровень приложений изменяется в соответствии с назначением этого конкретного приложения (или сервиса, API, app и т.д.)
Ответ №4:
Позвольте мне привести этот пример сценария корпоративного приложения, с которым я работал, чтобы объяснить, почему уровень домена и бизнес-уровень содержат бизнес-логику, но отличаются друг от друга.
Предположим, у меня есть продукт COTS, который является чистым механизмом управления обращениями, скажем, реализацией OMG CMMN. Целый набор бизнес-логики на бизнес-уровне, который работает с кучей объектов с уровня данных.
Теперь продолжим предположение, что у меня есть два клиента, которые являются системными интеграторами, один создает систему управления юридическими делами, а другой хочет управлять делами в сфере здравоохранения. оба являются управлением обращениями, но имеют свои собственные доменные термины, объекты, процедуры, отраслевые архитектуры и т.д.
Каждый из них добавит свой собственный уровень домена, чтобы они могли работать в терминах и концепциях соответствующего бизнес-домена.
Итак, да, он содержит бизнес-логику, но уровень домена — это способ инкапсуляции общего бизнеса многократного использования с конкретным бизнесом.
Чем «проще» приложение, тем более похожи модель домена и модель данных, а также бизнес-логика и логика домена. Но когда вы увеличиваете «полезность» компонента, они расходятся, в конечном итоге проблемы разделяются.