Доменные объекты/службы и бизнес-логический уровень

Ответ 1

Различные люди используют эти термины несколькими способами, но здесь я беру:

1) "Бизнес" и "домен" являются примерно синонимами. "Домен" немного более общий, поскольку он не делает предположение, что вы пишете бизнес-приложение. Поэтому, если мы пишем научное приложение или игру, мы можем предпочесть ссылаться на соответствующую часть кода как на код домена, а не на код "бизнес". Поэтому в оставшейся части этого объяснения я буду использовать "домен", поскольку он более общий.

2) "Логика домена" понимает как "объекты домена", так и "службы домена". По различным причинам (техническим и иным) многие архитектуры используют дизайн, в котором логика домена разделена на объекты для хранения данных ( "объекты домена" ) и объекты, которые ими управляют ( "службы домена" ). Мартин Фаулер и другие отметили, что это не очень OO, поскольку большая часть концепции OO заключается в том, чтобы добавить функциональность вместе с данными, и это право, Но что есть, то есть. Объектами домена являются данные и службы домена - это часть do-stuff-with-the-data.

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

Ответ 2

Уровень бизнес-логики также называется уровнем домена. Это уровень/уровень, который обрабатывает всю бизнес-логику.

Объекты домена и доменные службы - это классы, которые вы используете для создания своего домена.

Ответ 3

Нам нужно понять обязанности уровня приложения и уровня домена (бизнеса), чтобы иметь возможность понять разницу. Доменный уровень представляет бизнес-объекты, главным образом сущности из бизнеса, возможно, в некоторой степени абстрагированные и службы домена. Уровень домена изменяется только при изменении бизнеса или изменении контекста домена в бизнесе. Уровень приложения "живет" поверх уровня домена и часто (предпочтительно) отделен от уровня домена, например, с помощью веб-приложения asp.net MVC, где частью контроллера является прикладной уровень, а часть HTML является уровнем представления. Уровень приложения изменяется в соответствии с назначением этого конкретного приложения (или службы, API, приложения и т.д.).

Ответ 4

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

Предположим, что у меня есть продукт COTS, который является чистым механизмом управления случаями, скажем, реализация OMG CMMN. Целая группа бизнес-логики в бизнес-уровне, которая работает с кучей сущностей из уровня данных.

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

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

Итак, да, в нем содержится бизнес-логика, но уровень домена - это способ инкапсуляции общего многоразового бизнеса с конкретным бизнесом.

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