{"id":1880,"date":"2010-10-14T18:48:50","date_gmt":"2010-10-14T13:18:50","guid":{"rendered":"https:\/\/tothenewco.pro\/blog\/?p=1880"},"modified":"2017-04-24T15:52:19","modified_gmt":"2017-04-24T10:22:19","slug":"rich-domain-model-in-grails","status":"publish","type":"post","link":"https:\/\/tothenewco.pro\/blog\/rich-domain-model-in-grails\/","title":{"rendered":"Rich Domain Model in Grails"},"content":{"rendered":"

I have been working on grails<\/a> for quite some time now. As a beginner, I had doubts about where to place the business logic in grails. Seeing the CRUD, one can easily be misled into putting most of the code in the actions, but as the code base goes bigger, it becomes difficult to manage those actions. Coming from the java background, with the previous experience of putting just the getters and setters in the domain classes, it seemed hard for me to visualize business logic in the domain, so I started putting the business logic in the services. It is just natural to use actions as request welcoming and forwarding code blocks. As a result, the actions looked cleaner and easier to follow. The ability of the services to be transactional also simplified the saving of the objects.<\/p>\n

But, again as the code base grew, this type of approach also seemed to be unnatural. This approach surely has a tinge of procedural design in it. Devoiding domain objects of the behavior seem to be against the basic idea of object-oriented design. Martin Fowler <\/strong>has rightly called it as ‘Anemic Domain Model<\/strong>‘, depleting the domain classes of their behavior. To give you an example, for searching all the students of a teacher,<\/p>\n

\n
teacher.getAllStudents()<\/pre>\n<\/blockquote>\n
seems more natural than<\/p>\n
\n
teacherService.getAllStudents(teacher)<\/pre>\n<\/blockquote>\n
The former is more Object Oriented than the latter. Adding the behavior to the domain classes makes them rich, that is why it is called Rich Domain Model. The presence of grails dynamic finders in the domain classes seems to corroborate the model. Not only does the code become easier to understand but also becomes easier for some other developer to locate. Putting the business logic in the domain only is the natural way of Object Oriented Approach.<\/p>\n
But now the question comes what are services for in grails context? In my point of view, Services can be used on top of the business logic in the domain. So, they can encapsulate the different tasks in the application. The ability of Services to be transactional also make this approach natural.<\/p>\n
Hope this helps.<\/p>\n","protected":false},"excerpt":{"rendered":"
I have been working on grails for quite some time now. As a beginner, I had doubts about where to place the business logic in grails. Seeing the CRUD, one can easily be misled into putting most of the code in the actions, but as the code base goes bigger, it becomes difficult to manage […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":14,"footnotes":""},"categories":[7],"tags":[427,4005,438],"class_list":["post-1880","post","type-post","status-publish","format-standard","hentry","category-grails","tag-grails-design-pattern","tag-grails-development","tag-rich-domain-model"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t