Вопрос о моделях предметной области и их видимости
Я был вовлечен в интересные дебаты о видимости моделей предметной области и задавался вопросом, есть ли у людей здесь хорошее руководство.
- На мое понимание MDA мы не должны выставлять модель предметной области всюду по прикладным уровням и уровням
- Причем причина состоит в том, что любое изменение в модели предметной области оказывает влияние в полном приложении
- Мудрая вещь сделать состояла бы в том, чтобы выставить легкий объект (DTO), которые являются маленьким подмножеством модели предметной области для абстракции фактической модели
- На обороте любое изменение в модели предметной области означало бы изменять различный DTO всюду по приложению для изменения, чтобы быть видимым, в то время как, если мы действительно выставляем модель предметной области, затем изменение находится в единственном месте
Надежда видеть некоторые комментарии и мысли об этом.
Цените всю справку!
3 ответа
Нет, MDA не в этом. Речь идет об изоляции от определенных платформ с использованием нотации более высокого уровня (UML и его язык действий) для определения поведения системы.
Следует ли раскрывать модель предметной области, зависит от приложения. Для пользователей, которые регулярно используют приложение (подумайте о вашей IDE), модель предметной области будет четко представлена, и вы сможете напрямую манипулировать объектами в этом домене. Но для приложения, которое используется время от времени (подумайте о киоске в аэропорту для регистрации), оно должно направлять пользователя через рабочий процесс.
Даже если вы собираетесь экранировать объекты домена, DTO не обязательно нужны; это зависит от того, находятся ли объекты домена в том же пространстве процесса, что и слой, отображающий пользовательский интерфейс. Архитектуры, требующие DTO, не очень хорошо адаптируются к новым требованиям, потому что они нарушают принцип DRY.
Фактически, можно создавать корпоративные приложения исключительно из непосредственно открытых объектов домена; Это цель паттерна «Обнаженные объекты». Есть несколько фреймворков с открытым исходным кодом, которые реализуют это, в том числе оригинальная, Naked Objects Framework (на Java). Также существует коммерческий эквивалент .NET.
Для более подробного обсуждения объектов предметной области я рекомендую вам прочитать книгу Эванса «Дизайн, управляемый предметной областью». На Yahoo также есть активная группа новостей.
Дэн
полное раскрытие: я участник NOF для Java, не участвующий напрямую в версии .NET.
Я согласен с Дэном. Один из способов решить эту проблему - использовать интерфейсы. Вы заставляете свои общедоступные методы возвращать интерфейс, который изначально реализуют объекты вашего домена. Когда вы обнаружите, что возвращение объектов вашего домена из вашего приложения больше не работает, вы вводите свои DTO и реализуете соответствующий интерфейс.Несмотря на то, что внутреннее устройство вашей библиотеки изменилось, любые приложения-потребители останутся без изменений.
Я не слишком разбираюсь в этой области, но недавно я прочитал это сообщение в блоге Гойко Аджича , которое, на мой взгляд, актуально, о том, что DTO не обязательно являются хорошая идея, и это нормально, если ваша модель предметной области будет повторяться на отдельных уровнях, чтобы не нарушать DRY.