Ответ 1
Grails - это платформа par-excellence для реализации приложений в стиле Driven Design. В центре подхода Grails находятся классы домена, которые управляют всем процессом разработки. Как вы, наверное, догадываетесь, выбор доменного домена в Grails - это не просто совпадение.
Вы начинаете с определения своих классов доменов, а затем можете использовать Grails для выполнения всех тяжелых операций при сохранении и генерации графического интерфейса. Стоит отметить, что когда книга DDD была написана, это было до того, как были созданы Grails или другие подобные структуры, поэтому многие проблемы, затронутые в книге, связаны с проблемами, которые были решены или значительно сокращены рамками.
Некоторые концепции DDD, разрешенные Grails
Я использую описание шаблона DDD для адресации различных элементов DDD. (Котировки выделены курсивом в тексте ниже).
Модель домена
Модель домена структурирована через классы домена, службы, репозитории и другие шаблоны DDD. Давайте подробно рассмотрим каждую из них.
Объекты
"Когда объект отличается своей идентичностью, а не его атрибутами, сделайте это первичным для своего определения в модели"
Это классы домена в Grails. Они приходят с упорством, уже разрешенным через GORM. Модель может быть точно настроена с использованием GORM DSL. Взгляните на свойство hasOne vs. ownTo. Его можно использовать для определения жизненного цикла объектов и их отношений. attribTo приведет к каскадным ударам связанным объектам, а другим - нет. Итак, если у вас есть объект Car, вы можете сказать, что Motor "принадлежит" автомобилю, и в этом случае Car является агрегатным корнем и двигателем агрегатом. Обратите внимание, что я говорю здесь о соотношении жизненного цикла между сущностями, а не о сохранении.
Объекты значения
"Когда вы заботитесь только об атрибутах элемента модели, классифицируйте его как ОБЪЕКТ VALUE. Сделайте это, чтобы выразить смысл атрибутов, которые он передает, и дайте им связанные функции. Относитесь к объекту VALUE как непреложному. это любая личность..."
В Grails вы можете использовать "embedded" свойство в поле GORM для управления объектом значения. Объект Value может быть доступен только через объект, к которому он принадлежит, не имеет собственного идентификатора и сопоставляется с той же таблицей, что и объект, к которому он принадлежит. Groovy также поддерживает @Неизбежно аннотация, но я не уверен, как она играет с Grails.
Услуги
"Когда существенный процесс или преобразование в домене не является естественной ответственностью объекта ENTITY или VALUE, добавьте операцию в модель как автономный интерфейс, объявленный как СЕРВИС. Сделайте SERVICE без гражданства".
Так же, как сущности, службы поддерживаются в Grails. Вы размещаете свою службу Grails внутри каталога сервисов в проекте Grails. Услуги поставляются со следующей версией:
- Инъекция зависимостей
- Поддержка транзакций
- Простой механизм для предоставления услуг в виде веб-сервисов, так что к ним можно получить доступ удаленно.
Модули
"Выберите MODULES, которые расскажут историю системы и содержат сплоченный набор понятий".
Grails plug-in механизм предоставляет это и многое другое: очень простой способ установки и создания плагинов, определяет, как приложение может переопределять плагины и т.д..
Заполнители
"Скопируйте объекты ENVTIES и VALUE в AGGREGATES и определите границы вокруг каждого. Выберите один ENTITY, чтобы быть корнем каждого AGGREGATE, и контролируйте весь доступ к объектам внутри границы через корень. Разрешить внешним объектам удерживать ссылки на только корень."
Я уже упомянул некоторые механизмы управления жизненным циклом. Вы можете использовать службы Grails Services и механизм контроля доступа к языку для обеспечения контроля доступа. У вас может быть служба Grails, играющая роль репозитория DDD, который разрешает доступ только к Aggregate Root. Хотя контроллеры в Grails могут напрямую обращаться к операциям GORM на Entities, я бы утвердил, что для лучшего многоуровневого дизайна контроллерам необходимо вводить услуги, которые делегируются операциям GORM Active Record.
Заводы
"Сменить ответственность за создание экземпляров сложных объектов и AGGREGATES на отдельный объект, который сам по себе не может нести ответственность в модели домена, но все еще является частью дизайна домена."
Groovy builders - отличная альтернатива для построения сложных объектов через богатый DSL. В DDD заводы более свободны и не переходят непосредственно к GoF Аннотация Factory или Factory Метод. Groovy сборщики - это реализация DSL шаблона GoF Builder.
Хранилища
"Для каждого типа объекта, который нуждается в глобальном доступе, создайте объект, который может обеспечить иллюзию коллекции в памяти всех объектов такого типа. Настройте доступ через общеизвестный глобальный интерфейс. и удалять объекты, которые будут инкапсулировать фактическую вставку или удаление данных в хранилище данных. Предоставить методы, которые выбирают объекты на основе некоторых критериев и возвращать полностью созданные объекты или коллекции объектов, значения атрибутов которых соответствуют критериям, тем самым инкапсулируя фактическое хранилище и технологии запросов. Предоставляйте репозитории только для корней AGGREGATE, которые фактически нуждаются в прямом доступе. Держите клиента ориентированным на модель, делегируя все хранение объектов и доступ к REPOSITORIES."
Служба Grails может использоваться для реализации выделенного объекта репозитория, который просто делегирует свою работу Grails GORM. Стойкость решена с магией GORM. Каждый класс домена предоставляет набор динамических методов, которые разрешают типичные операции CRUD, включая запрос ad-hock.
Утверждения
"Состояние пост-условий операций и инвариантов классов и AGGREGATES. Если ASSERTIONS не могут быть закодированы непосредственно на вашем языке программирования, напишите им автоматические модульные тесты".
- Взгляните на аннотации Groovy @Invariant, @Requires, @Ensures, они могут быть использованы для объявления индексов инвариантов DbC и Pre и постусловия
- Когда вы создаете классы домена с помощью командной строки Grails, тестовые классы создаются автоматически, и это еще один механизм выражения утверждений в вашем домене.
Декларативный стиль дизайна
"Гибкий дизайн может позволить клиентскому коду использовать декларативный стиль дизайна. Чтобы проиллюстрировать, следующий раздел объединит некоторые из шаблонов в этой главе, чтобы сделать СПЕЦИФИКАЦИЯ более гибкой и декларативной".
Здесь Grails выделяется из-за динамической природы Groovy языка и поддержки шаблонов Builder для создания пользовательских DSL.
Многоуровневая архитектура
Приходит "из коробки" с Grails через предлагаемую "" Конвент Конфигурация" в виде многоуровневой MVC.