Вопрос о моделях доменов и их видимости - PullRequest
6 голосов
/ 05 мая 2010

Я участвовал в интересной дискуссии о видимости моделей предметной области и задавался вопросом, есть ли у людей здесь какие-либо хорошие рекомендации.

  • Согласно моему пониманию MDA, нам не нужно раскрывать модель предметной области на всех уровнях и уровнях приложения
  • Причина в том, что любое изменение модели предметной области оказывает влияние на общее приложение
  • Мудрее всего было бы выставить легкий объект (DTO), являющийся небольшим подмножеством модели предметной области, для абстрагирования фактической модели
  • С другой стороны, любое изменение модели предметной области будет означать изменение различных DTO во всем приложении, чтобы изменение было видимым, в то время как если мы представим модель предметной области, то это изменение будет в одном месте

Надеюсь увидеть некоторые комментарии и мысли по этому поводу.

Ценю всю помощь!

Ответы [ 3 ]

2 голосов
/ 05 мая 2010

Нет, это не то, чем занимается MDA. Речь идет о самоизоляции от конкретных платформ с использованием нотации более высокого уровня (UML и его языка действий) для определения поведения системы.

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

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

Фактически, возможно создавать корпоративные приложения исключительно из открытых доменных объектов; это цель модели «Голые объекты». Существует несколько сред с открытым исходным кодом, которые реализуют это, в том числе оригинальная платформа Naked Objects Framework (на Java). Есть также коммерческий эквивалент для .NET.

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

Dan

полное раскрытие: я приверженец NOF для Java, напрямую не участвую в версии .NET.

0 голосов
/ 02 июля 2010

Я не слишком хорошо осведомлен в этой области, но я недавно прочитал это сообщение в блоге Гойко Адзича , которое, на мой взгляд, актуально, о том, что DTO не обязательно хорошая идея, и что это нормально для повторить модель вашего домена на разных уровнях, чтобы не нарушать DRY.

0 голосов
/ 28 июня 2010

Я согласен с Дэном. Одним из способов решения этой проблемы является использование интерфейсов. Вы заставляете ваши публичные методы возвращать интерфейс, который изначально реализуют ваши доменные объекты. Когда вы обнаружите, что возврат ваших доменных объектов из вашего приложения больше не работает, вы вводите свои DTO и реализуете соответствующий интерфейс. Хотя внутренняя часть вашей библиотеки теперь изменилась, все приложения-потребители останутся без изменений.

...