Paul
Paul

Reputation: 2581

DDD with Grails

I cannot find any info about doing Domain Driven Design (DDD) with Grails.

I'm looking for any best practices, experience notes or even open source projects that are good examples of DDD with Grails.

Upvotes: 15

Views: 4972

Answers (7)

pzajdel
pzajdel

Reputation: 15

www.infoq.com/articles/ddd-in-practice

"Frameworks like Spring and Real Object Oriented (ROO), Hibernate, and Dozer aid in designing and implementing a domain model. Other frameworks that support DDD implementation are JMatter, Naked Objects, Ruby On Rails, Grails, and Spring Modules XT Framework."

grails.org/doc/latest/guide/introduction.html

"Dynamic frameworks like Rails, Django and TurboGears helped pave the way to a more modern way of thinking about web applications. Grails builds on these concepts and dramatically reduces the complexity of building web applications on the Java platform. What makes it different, however, is that it does so by building on already established Java technologies like Spring and Hibernate."

Bascily what works with Spring, will also work with Grails.

I hope some day community will provide us all with ddd-sample written in Grails.

dddsample.sourceforge.net

// spam mech doesn't allow me to put more than two links in one post, soz

Upvotes: 0

Danijel Arsenovski
Danijel Arsenovski

Reputation: 519

Grails is par-excellence platform for implementing applications in Domain Driven Design style . At the center of Grails approach are Domain Classes that drive the whole development process. As you are probably guessing, the choice of word domain in Grails is not just a coincidence.

You start by defining your Domain Classes and then you can use Grails to do all heavy lifting in providing persistence and generating the GUI. It's worth noting that when the DDD book was written, it was before the Grails or other similar frameworks were created, so a lot of problematic dealt with in a book has to do with issues resolved or greatly reduced by the framework.

Some of DDD concepts resolved by Grails

I will use DDD pattern summary to address different DDD elements. (Quotes italicized in the text below).

Domain Model

Domain model is structured through Domain classes, Services, Repositories and other DDD Patterns. Let’s take a look at each of these in detail.

Entities

“When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model”

These are Domain Classes in Grails. They come with persistence already resolved through GORM. Model can be finely tuned using the GORM DSL. Take a look at hasOne vs. belongsTo property. It can be used to define the lifecycle of entities and their relationships. belongsTo will result in cascading deletes to related entities and other will not. So, if you have a Car object, you can say that Motor “belongsTo” a Car and in that case Car is an Aggregate Root and Motor an aggregate. Note that am I talking here about lifecycle relationship between entities and not the persistence.

Value Objects

“When you care only about the attributes of an element of the model, classify it as a VALUE OBJECT. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the VALUE OBJECT as immutable. Don’t give it any identity…”

In Grails, you can use “embedded” property in GORM field to manage a value object. Value object can be accessed only through an entity it belongs to, does not have its own ID and is mapped to same table as the entity it belongs to. Groovy also supports @Immutable annotation but I am not sure how it plays with Grails.

Services

“When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Make the SERVICE stateless.”

Just like Entities, Services are natively supported in Grails. You place your Grails Service inside the services directory in your Grails project. Services come with following out of the box:

  • Dependency Injection
  • Transaction Support
  • A simple mechanism for exposing services as web services, so that they can be accessed remotely.

Modules

“Choose MODULES that tell the story of the system and contain a cohesive set of concepts. “

Grails plug-in mechanism provides this and much more: a very simple way to install and create plugins, defines how application can override plugins etc.

Aggregates

“Cluster the ENTITIES and VALUE OBJECTS into AGGREGATES and define boundaries around each. Choose one ENTITY to be the root of each AGGREGATE, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to the root only.”

I already mentioned some lifecycle control mechanisms. You can use Grails Services and language access control mechanism to enforce access control. You can have a Grails Service playing the role of DDD Repository that permits access to Aggregate Root only. While Controllers in Grails can access GORM operations on Entities directly, I'd argue that for better layered design, Controllers should be injected with services that delegate to GORM Active Record operations.

Factories

“Shift the responsibility for creating instances of complex objects and AGGREGATES to a separate object, which may itself have no responsibility in the domain model but is still part of the domain design.”

Groovy builders are excellent alternative for constructing complex objects through rich DSL. In DDD, Factories are more loose term and does not translate directly to GoF Abstract Factory or Factory Method. Groovy builders are DSL implementation of GoF Builder pattern.

Repositories

“For each type of object that needs global access, create an object that can provide the illusion of an in-memory collection of all objects of that type. Set up access through a well-known global interface. Provide methods to add and remove objects, which will encapsulate the actual insertion or removal of data in the data store. Provide methods that select objects based on some criteria and return fully instantiated objects or collections of objects whose attribute values meet the criteria, thereby encapsulating the actual storage and query technology. Provide repositories only for AGGREGATE roots that actually need direct access. Keep the client focused on the model, delegating all object storage and access to the REPOSITORIES.”

Grails Service can be used to implement a dedicated Repository object that simply delegates its operation to Grails GORM. Persistence is resolved with GORM magic. Each Domain class provides a set of dynamic methods that resolve typical CRUD operations including ad-hock querying.

Assertions

“State post-conditions of operations and invariants of classes and AGGREGATES. If ASSERTIONS cannot be coded directly in your programming language, write automated unit tests for them.”

  • Take a look at Groovy @Invariant, @Requires, @Ensures annotations, these can be used to declare DbC style Invariants and Pre and Postconditions
  • When you create your domain classes with Grails command line, test classes are created automatically and these are another mechanism for expressing assertions in your domain.

Declarative Style of Design

“A supple design can make it possible for the client code to use a declarative style of design. To illustrate, the next section will bring together some of the patterns in this chapter to make the SPECIFICATION more supple and declarative.”

This is where Grails excels because of dynamic nature of Groovy language and Builder pattern support for creating custom DSLs.

Layered Architecture

Comes “out-of-the-box” with Grails through proposed “Convention over Configuration” application structure in a form of a layered MVC based implementation.

Upvotes: 36

thomas.han
thomas.han

Reputation: 3018

DDD is technology agnostic way of organizing software.

Yes DDD can be implemented using Grails.

Sudarshan you've pointed out Grails doesn't handle the concept of aggregate roots. Does any framework you've worked with have the concept of aggregate root? Frameworks itself shouldn't have the concepts of DDD (unless it self is an DDD framework, but I haven't come across DDD frameworks yet).

It is an idea and should be technology agnostic therefore it is up to the application developers to incorporate such concepts. In Grails it is a bit hard to distinguish between an entity and aggregate root using static methods such as Person.get(1) or Person.findByName("name") but that is not the point. It is therefore the developers' responsibility to distinguish this by some other means such as use of convention.

Upvotes: 2

user427165
user427165

Reputation:

I found this article it may be of some interest. I have quoted the main line of interest.

"DK: Grails' dynamic and extensible scaffolding makes it easy to apply principles of DDD, without the limits and complexity of some DDD frameworks."

http://www.infoq.com/articles/klein-grailsquickstartguide

Upvotes: 0

Sudarshan
Sudarshan

Reputation: 8664

After reading this question I have done a little reading up both on DDD and Grails. I am not sure if grails was meant to support DDD though.

However I have read on some posts that Grails does support DDD Grails and DDD

However I think Grails mainly backs the Active record pattern, Explained here

For Grails every domain object is a aggregate root, this by itself is against DDD.

Grails Aggregate Root Workaround

DDD Java Implementation , can we have a similar Grails DDD implementation sample ?

A lot of things like repositories can easily be implemented through Grails , I really like it and think that it increases productivity.

However I have my doubts when people say that Grails and DDD go hand in hand.

Upvotes: 3

lunohodov
lunohodov

Reputation: 5399

Currently I am not aware of any books that relate to Grails and DDD. Personally I would not concentrate on Grails only. Domain Driven Design is a way of thinking, a way of organizing your application and code. Thus it is not bound to technology.

The MVC paradigm does not consider models to be data access objects. In fact it does not even mention the data access layer as it is understood to be underneath/encapsulated by the model. This introduces some pitfalls when trying to utilize DDD with MVC technologies based on the ActiveRecord pattern which merges domain logic and data access code into the model. It works very well... especially in simple applications with little domain logic where there is no real distinction to be made. But when things get more complex, one should keep in mind that model != data access.

Personally I would consider improving my understanding of DDD:

Cheers!

Upvotes: 7

firnnauriel
firnnauriel

Reputation: 2063

try reading Grails in Action, it's in Chapter 3. it is presented by letting you work on a sample project and even shows step-by-step procedure on how to build it from scratch as well as adding plugins, etc. I highly recommend that book, very valuable reference.

note that i'm a new grails user too.

Upvotes: -3

Related Questions