анемичная модель предметной области по сравнению с моделью предметной области
Java имел закрытия с тех пор 1.1, только очень громоздким и ограниченным способом.
Они часто полезны везде, где у Вас есть обратный вызов некоторого описания. Общий падеж должен абстрагировать далеко поток управления, оставив интересный код для вызова алгоритма с закрытием, которое не имеет никакого потока внешнего управления.
А тривиальный пример для - каждый (хотя Java 1.5 уже имеет это). Пока можно реализовать forEach метод в Java как есть, это является слишком подробным, чтобы быть полезным.
пример, который уже имеет смысл с существующим Java, реализует, "выполняются вокруг" идиомы, посредством чего приобретение ресурса и выпуск абстрагированы. Например, открытый файл и близко может быть сделан в рамках попытки/наконец без клиентского кода, имеющего необходимость разобраться в деталях.
3 ответа
Она становится «реальной» моделью предметной области, когда она содержит все (или большую часть) поведения , составляющего бизнес-домен (примечание I Я подчеркиваю бизнес-логику , а не пользовательский интерфейс или другие ортогональные проблемы).
Если вы используете повсеместный язык и получаете постоянную обратную связь от вашего эксперты в предметной области , вы будете знать, что вы на правильном пути (эксперты должны кивать, когда видят вашу модель предметной области). Если вы этого не делаете, вы не выполняете DDD ( Эрик Эванс говорит об этом ).
Что касается DTO: не игнорируйте их. С точки зрения реализации они понадобятся вам для передачи данных между слоями / уровнями.
На ум приходят два интересных момента:
- Объекты передачи данных (DTO) отличаются от объектов домена. Они служат разным целям в разных частях архитектуры - не путайте их. Объекты домена предоставляют богатый API с высокой связностью . DTO - это пассивные структуры данных , используемые во внешнем интерфейсе приложения - в точности как UI ViewModels, но нацеленные на автоматизированные системы, а не на пользователей.
- Стремитесь выбрать ORM, который позволяет вам использовать Persistence Ignorance . Это означает, что вы можете определить свою модель домена неограниченным образом и просто заставить ORM сопоставить объекты с реляционной базой данных.
Но если я добавлю достаточно логики предметной области в эту оболочку, в какой момент она станет реальной моделью предметной области, тогда ?
Достижение модели предметной области посредством добавления материала случайным образом возможно, но, конечно, не проектирование, основанное на предметной области. (Я знаю, что это бесполезно. Я сам склонен думать очень ориентированным на данные, и в некоторых случаях требуется реальное усилие, чтобы оттолкнуться от этой точки зрения.)