Я знаю, что прошло много времени с момента последнего сообщения здесь.Но важно, чтобы информация вокруг этой концепции была ясной.Доменная модель часто представляет собой набор классов, которые представляют конкретную проблемную область.Концепция не связана с каким-либо одним типом реализации технологии.Я думаю, что немного вводить в заблуждение, говоря:
" Экземпляры модели домена часто необходимо сохранять в базе данных, а в Java они обычно соответствуют спецификации Java Beans, то есть имеютустановите методы для представления отдельных свойств и конструктора без параметров. Spring и другие платформы позволяют вам получать доступ к этим свойствам непосредственно в ваших JSP"
. Доменные модели часто являются результатом проектирования, управляемого доменом.Проектирование на основе домена является ключом к хорошей и надежной модели домена.Я предлагаю прочитать книгу Эрика Эванса «Домен, управляемый дизайном», чтобы лучше понять.
Классы доменной модели имеют информацию, связанную с ними, но поведение, на мой взгляд, важнее данных в этом контексте.Большая ошибка при проектировании, управляемом доменом, заключается в создании классов данных, которые представляют данные объекта домена, такого как customer, и предоставляют только общедоступные методы получения и установки для атрибутов клиента.Эти объекты, как правило, просто имитируют структуру вашей базы данных, и в результате фактическая бизнес-логика с большей вероятностью будет находиться в доменных службах, в результате чего модель анемичного домена .Эта модель ближе к Transaction Script , чем модель предметной области.