Weak-Ass Domain Objects

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Weak-Ass Domain Objects

Gary Affonso
Grails' hot-reloading (specifically, the inconsistent lack of it) is driving me crazy.

The hot-reloading of changes to domain objects is all over the place.  Sometimes is lets me make and see the change in a running server.  Sometimes, after I make a code-change, it tells me it can't find the createCriteria method (presumably, the domain object loses its meta/mix-in grooviness).  Sometimes, after making a code-change, it gives me a LazyInitializationException.  Sometimes errors are deviously subtle (like out-of-sync fields when doing a dbm-gorm-diff after a domain-class change without a "clean" first.

But only sometimes.

I tend to agree with Fowler that weak-ass domain objects are an anti-pattern...

  http://en.wikipedia.org/wiki/Anemic_domain_model

But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib).

I would vastly prefer better (or at least consistent and predictable) hot-reloading of domain classes.  Actually, I would love *consistent* and *predictable* behavior for hot-reloading through the grails infrastructure.  I get that hot-reload might not be possible or practical for all cases, but the inconsistency is causing me to throw up my hands and just give up on it all together.

Any solution is sight?  Or maybe I'm the only one this bothers?

Thanks!

- Gary

P.S.  Running Grails 2.0.4, still not ready to bite off a 2.1 upgrade.

P.P.S Grails 2.0.4 seems to be worse about hot-reload than grails 2.0.3

P.P.P.S.  Is it irony I smell?  Grail adds a lot of functionality TO domain objects (dynamic finders, etc.), is also creating a development environment which discourages me (with hot-reload wonkiness) from doing the same.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Dean Del Ponte-2
You may want to prioritize the upgrade to grails 2.1.x

We recently upgraded a large app from 2.0.4 to 2.1.x and it was painless

2.1.x may fix the problems you're experiencing:  http://jira.grails.org/browse/GRAILS-9213

Regards,

Dean Del Ponte 

On Fri, Aug 17, 2012 at 2:38 PM, Gary Affonso <[hidden email]> wrote:
Grails' hot-reloading (specifically, the inconsistent lack of it) is driving me crazy.

The hot-reloading of changes to domain objects is all over the place.  Sometimes is lets me make and see the change in a running server.  Sometimes, after I make a code-change, it tells me it can't find the createCriteria method (presumably, the domain object loses its meta/mix-in grooviness).  Sometimes, after making a code-change, it gives me a LazyInitializationException.  Sometimes errors are deviously subtle (like out-of-sync fields when doing a dbm-gorm-diff after a domain-class change without a "clean" first.

But only sometimes.

I tend to agree with Fowler that weak-ass domain objects are an anti-pattern...

  http://en.wikipedia.org/wiki/Anemic_domain_model

But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib).

I would vastly prefer better (or at least consistent and predictable) hot-reloading of domain classes.  Actually, I would love *consistent* and *predictable* behavior for hot-reloading through the grails infrastructure.  I get that hot-reload might not be possible or practical for all cases, but the inconsistency is causing me to throw up my hands and just give up on it all together.

Any solution is sight?  Or maybe I'm the only one this bothers?

Thanks!

- Gary

P.S.  Running Grails 2.0.4, still not ready to bite off a 2.1 upgrade.

P.P.S Grails 2.0.4 seems to be worse about hot-reload than grails 2.0.3

P.P.P.S.  Is it irony I smell?  Grail adds a lot of functionality TO domain objects (dynamic finders, etc.), is also creating a development environment which discourages me (with hot-reload wonkiness) from doing the same.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

KillDash9

Straight Spring 3 with JRebel is what I'm headed back to. Works great. Sorry guys.

On Aug 17, 2012, at 3:48 PM, Dean Del Ponte <[hidden email]> wrote:

You may want to prioritize the upgrade to grails 2.1.x

We recently upgraded a large app from 2.0.4 to 2.1.x and it was painless

2.1.x may fix the problems you're experiencing:  http://jira.grails.org/browse/GRAILS-9213

Regards,

Dean Del Ponte 

On Fri, Aug 17, 2012 at 2:38 PM, Gary Affonso <[hidden email]> wrote:
Grails' hot-reloading (specifically, the inconsistent lack of it) is driving me crazy.

The hot-reloading of changes to domain objects is all over the place.  Sometimes is lets me make and see the change in a running server.  Sometimes, after I make a code-change, it tells me it can't find the createCriteria method (presumably, the domain object loses its meta/mix-in grooviness).  Sometimes, after making a code-change, it gives me a LazyInitializationException.  Sometimes errors are deviously subtle (like out-of-sync fields when doing a dbm-gorm-diff after a domain-class change without a "clean" first.

But only sometimes.

I tend to agree with Fowler that weak-ass domain objects are an anti-pattern...

  http://en.wikipedia.org/wiki/Anemic_domain_model

But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib).

I would vastly prefer better (or at least consistent and predictable) hot-reloading of domain classes.  Actually, I would love *consistent* and *predictable* behavior for hot-reloading through the grails infrastructure.  I get that hot-reload might not be possible or practical for all cases, but the inconsistency is causing me to throw up my hands and just give up on it all together.

Any solution is sight?  Or maybe I'm the only one this bothers?

Thanks!

- Gary

P.S.  Running Grails 2.0.4, still not ready to bite off a 2.1 upgrade.

P.P.S Grails 2.0.4 seems to be worse about hot-reload than grails 2.0.3

P.P.P.S.  Is it irony I smell?  Grail adds a lot of functionality TO domain objects (dynamic finders, etc.), is also creating a development environment which discourages me (with hot-reload wonkiness) from doing the same.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Dean Del Ponte-2
Or instead of upgrading to 2.1.x you could do that  ;)

On Fri, Aug 17, 2012 at 3:04 PM, Michael Andrews <[hidden email]> wrote:

Straight Spring 3 with JRebel is what I'm headed back to. Works great. Sorry guys.

On Aug 17, 2012, at 3:48 PM, Dean Del Ponte <[hidden email]> wrote:

You may want to prioritize the upgrade to grails 2.1.x

We recently upgraded a large app from 2.0.4 to 2.1.x and it was painless

2.1.x may fix the problems you're experiencing:  http://jira.grails.org/browse/GRAILS-9213

Regards,

Dean Del Ponte 

On Fri, Aug 17, 2012 at 2:38 PM, Gary Affonso <[hidden email]> wrote:
Grails' hot-reloading (specifically, the inconsistent lack of it) is driving me crazy.

The hot-reloading of changes to domain objects is all over the place.  Sometimes is lets me make and see the change in a running server.  Sometimes, after I make a code-change, it tells me it can't find the createCriteria method (presumably, the domain object loses its meta/mix-in grooviness).  Sometimes, after making a code-change, it gives me a LazyInitializationException.  Sometimes errors are deviously subtle (like out-of-sync fields when doing a dbm-gorm-diff after a domain-class change without a "clean" first.

But only sometimes.

I tend to agree with Fowler that weak-ass domain objects are an anti-pattern...

  http://en.wikipedia.org/wiki/Anemic_domain_model

But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib).

I would vastly prefer better (or at least consistent and predictable) hot-reloading of domain classes.  Actually, I would love *consistent* and *predictable* behavior for hot-reloading through the grails infrastructure.  I get that hot-reload might not be possible or practical for all cases, but the inconsistency is causing me to throw up my hands and just give up on it all together.

Any solution is sight?  Or maybe I'm the only one this bothers?

Thanks!

- Gary

P.S.  Running Grails 2.0.4, still not ready to bite off a 2.1 upgrade.

P.P.S Grails 2.0.4 seems to be worse about hot-reload than grails 2.0.3

P.P.P.S.  Is it irony I smell?  Grail adds a lot of functionality TO domain objects (dynamic finders, etc.), is also creating a development environment which discourages me (with hot-reload wonkiness) from doing the same.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Octavian Covalschi
In reply to this post by KillDash9
Yeah, my apples are sweeter  than your oranges... 

On Fri, Aug 17, 2012 at 3:04 PM, Michael Andrews <[hidden email]> wrote:
Straight Spring 3 with JRebel is what I'm headed back to. Works great. Sorry guys.

Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

ideasculptor
In reply to this post by Dean Del Ponte-2


On Fri, Aug 17, 2012 at 1:27 PM, Dean Del Ponte <[hidden email]> wrote:
Or instead of upgrading to 2.1.x you could do that  ;)


The problem is that without absolutely reliable consistency in behaviour, most of the productivity gains of not having to redeploy after every change disappear in every case except where your test is successful.  In any kind of test failure, it actually slows you down, since the developer's process now becomes make change -> test change -> restart app in case test failure was result of failed reload - test again.  I am so much in the habit of having to restart in order to verify test failures that I don't even bother trying to test against a currently running instance unless my change is so minor that it is highly unlikely to see a test failure.   


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Dean Del Ponte-2
I can honestly say I don't experience this problems running in Grails-2.1.x

On Fri, Aug 17, 2012 at 4:13 PM, Samuel Gendler <[hidden email]> wrote:


On Fri, Aug 17, 2012 at 1:27 PM, Dean Del Ponte <[hidden email]> wrote:
Or instead of upgrading to 2.1.x you could do that  ;)


The problem is that without absolutely reliable consistency in behaviour, most of the productivity gains of not having to redeploy after every change disappear in every case except where your test is successful.  In any kind of test failure, it actually slows you down, since the developer's process now becomes make change -> test change -> restart app in case test failure was result of failed reload - test again.  I am so much in the habit of having to restart in order to verify test failures that I don't even bother trying to test against a currently running instance unless my change is so minor that it is highly unlikely to see a test failure.   



Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Gary Affonso
In reply to this post by Gary Affonso
Will re-priortize the 2.1 upgrade and see where it takes me.

Thanks guys!

- Gary

On Aug 17, 2012, at 12:38 PM, Gary Affonso wrote:

> Grails' hot-reloading (specifically, the inconsistent lack of it) is driving me crazy.
>
> The hot-reloading of changes to domain objects is all over the place.  Sometimes is lets me make and see the change in a running server.  Sometimes, after I make a code-change, it tells me it can't find the createCriteria method (presumably, the domain object loses its meta/mix-in grooviness).  Sometimes, after making a code-change, it gives me a LazyInitializationException.  Sometimes errors are deviously subtle (like out-of-sync fields when doing a dbm-gorm-diff after a domain-class change without a "clean" first.
>
> But only sometimes.
>
> I tend to agree with Fowler that weak-ass domain objects are an anti-pattern...
>
>  http://en.wikipedia.org/wiki/Anemic_domain_model
>
> But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib).
>
> I would vastly prefer better (or at least consistent and predictable) hot-reloading of domain classes.  Actually, I would love *consistent* and *predictable* behavior for hot-reloading through the grails infrastructure.  I get that hot-reload might not be possible or practical for all cases, but the inconsistency is causing me to throw up my hands and just give up on it all together.
>
> Any solution is sight?  Or maybe I'm the only one this bothers?
>
> Thanks!
>
> - Gary
>
> P.S.  Running Grails 2.0.4, still not ready to bite off a 2.1 upgrade.
>
> P.P.S Grails 2.0.4 seems to be worse about hot-reload than grails 2.0.3
>
> P.P.P.S.  Is it irony I smell?  Grail adds a lot of functionality TO domain objects (dynamic finders, etc.), is also creating a development environment which discourages me (with hot-reload wonkiness) from doing the same.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Sebastian Gozin
You can greatly reduce the need for gorm level changes on a running server by testing with the in-memory-gorm implementation.
See the testing chapter in the grails documentation.

Also a little bit of advice.
Gorm objects are not domain objects. They are database artifacts. Keep your business logic in your domain objects where they belong.
That way you can test your business logic without a server or a database.

- Sebastian

On 18 Aug 2012, at 05:12, Gary Affonso wrote:

> Will re-priortize the 2.1 upgrade and see where it takes me.
>
> Thanks guys!
>
> - Gary
>
> On Aug 17, 2012, at 12:38 PM, Gary Affonso wrote:
>
>> Grails' hot-reloading (specifically, the inconsistent lack of it) is driving me crazy.
>>
>> The hot-reloading of changes to domain objects is all over the place.  Sometimes is lets me make and see the change in a running server.  Sometimes, after I make a code-change, it tells me it can't find the createCriteria method (presumably, the domain object loses its meta/mix-in grooviness).  Sometimes, after making a code-change, it gives me a LazyInitializationException.  Sometimes errors are deviously subtle (like out-of-sync fields when doing a dbm-gorm-diff after a domain-class change without a "clean" first.
>>
>> But only sometimes.
>>
>> I tend to agree with Fowler that weak-ass domain objects are an anti-pattern...
>>
>> http://en.wikipedia.org/wiki/Anemic_domain_model
>>
>> But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib).
>>
>> I would vastly prefer better (or at least consistent and predictable) hot-reloading of domain classes.  Actually, I would love *consistent* and *predictable* behavior for hot-reloading through the grails infrastructure.  I get that hot-reload might not be possible or practical for all cases, but the inconsistency is causing me to throw up my hands and just give up on it all together.
>>
>> Any solution is sight?  Or maybe I'm the only one this bothers?
>>
>> Thanks!
>>
>> - Gary
>>
>> P.S.  Running Grails 2.0.4, still not ready to bite off a 2.1 upgrade.
>>
>> P.P.S Grails 2.0.4 seems to be worse about hot-reload than grails 2.0.3
>>
>> P.P.P.S.  Is it irony I smell?  Grail adds a lot of functionality TO domain objects (dynamic finders, etc.), is also creating a development environment which discourages me (with hot-reload wonkiness) from doing the same.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Gary Affonso

On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Roberto Guerra
Yap, sadly so. It is Rails disease that has infected these new web frameworks. 
But you don't have to depend on these domain models. You can create real domain models in separate jars and map them using hibernate or mybatis. And you can use grails just as a 'delivery mechanism'.
You can still apply good design concepts on these frameworks : vimeo.com/43612849
Here is a blog post about an attempt at doing hexagonal architecture on grails: http://stumblingoncode.wordpress.com/2012/07/26/78/
It's just a poc that it can be done.

On Sat, Aug 18, 2012 at 2:55 PM, Gary Affonso <[hidden email]> wrote:

On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

barnesjd
In reply to this post by Gary Affonso
Gary Affonso wrote
...But grails is kicking my butt with hot-reloading bullshit every time I try to develop/debug my own code located within a domain object while an app is running.  This is causing me to move as much code as possible out of my domain objects and into code-locations that are more compatible with hot-reloading (like a taglib)...
If I've understood you correctly, you're testing with your app running?  In the past few months, I've really bought into test-driven development and I have been very happy with the change.  Not only do I greatly appreciate the approach, I don't hit the reloading issues when doing this in Grails.  

Now as for the weak domain objects, I love Fowler but I'm not a big fan of his stance on this issue... but that's a different discussion I'm sure.  I'd rather convince you that TDD is the way to go than bicker about domain objects.

Joe
Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Nathan Wells
In reply to this post by Roberto Guerra
First, let me say, let's tone down the expletives, OK? We all get frustrated, but there's no need to pollute the list with lazy language.

Secondly, with no disrespect intended, just because Martin Fowler describes something as an anti-pattern doesn't make it an anti-pattern. There are certainly cases where a fully-realized "domain model" is called for, but it's not a panacea. In my experience, it often adds significant accidental complexity, as I spend time, not worrying about the accurate resolution of the business problem, but bikeshedding about the placement of code (should ObjA or ObjB be the controller in this instance?).

This kind of object-oriented purism is why some people eschew Java. Sometimes a functional implementation is the best approach to solve a business problem, even if it doesn't "model" the problem correctly. This is why a lot of really smart programmers go to multi-paradigm languages like Ruby, Python, Javascript, and Groovy. They'd rather solve business problems than worry about what level of Fowler-Nirvana they've achieved.

</rant>

Oh, yeah, and TDD would work great for you :)

Nathan Wells


On Sat, Aug 18, 2012 at 3:15 PM, Roberto Guerra <[hidden email]> wrote:
Yap, sadly so. It is Rails disease that has infected these new web frameworks. 
But you don't have to depend on these domain models. You can create real domain models in separate jars and map them using hibernate or mybatis. And you can use grails just as a 'delivery mechanism'.
You can still apply good design concepts on these frameworks : vimeo.com/43612849
Here is a blog post about an attempt at doing hexagonal architecture on grails: http://stumblingoncode.wordpress.com/2012/07/26/78/
It's just a poc that it can be done.

On Sat, Aug 18, 2012 at 2:55 PM, Gary Affonso <[hidden email]> wrote:

On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
The Journey Is The Reward.

Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Sebastian Gozin
In reply to this post by Roberto Guerra
That is exactly what I mean yes.

The classes in the grails domain folder are GORM artifacts right? They are all about providing convenient ORM wrapping to different databases.
Even though they do this reasonably well you will still encounter technical limitations of the chosen persistence strategy (e.g: hibernate, redis, etc...)
That said GORM is a really great technology and it does help you to remove a lot of the boiler plate you'd normally be confronted with.

Your domain, isn't about persistence. It's about business rules. You would like to be free to model this based on the requirements of your domain and not your chosen database.
So in that sense, even if Grails calls them "domain" they really are just DTO on steroids as you say.

What I tend to do is build real domain objects which interact with repositories which wrap my GORM entities.

- Sebastian

PS: I've seen some posts arguing that Fowler may be going a bit overboard. Going so far as to call it OO purism.
I don't subscribe to that. It's probably just difficult to fully understand what he means and how you can apply it.


On 18 Aug 2012, at 23:15, Roberto Guerra wrote:

Yap, sadly so. It is Rails disease that has infected these new web frameworks. 
But you don't have to depend on these domain models. You can create real domain models in separate jars and map them using hibernate or mybatis. And you can use grails just as a 'delivery mechanism'.
You can still apply good design concepts on these frameworks : vimeo.com/43612849
Here is a blog post about an attempt at doing hexagonal architecture on grails: http://stumblingoncode.wordpress.com/2012/07/26/78/
It's just a poc that it can be done.

On Sat, Aug 18, 2012 at 2:55 PM, Gary Affonso <[hidden email]> wrote:

On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
The Journey Is The Reward.

Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

jonspalmer
In reply to this post by Roberto Guerra

I feel like this misses the point a little about ‘rapid development’ frameworks like Grails. One of the core ideas is to have the framework remove the boiler plate code, give you convention over configuration and allow you to have less code better focused on actually solving your business problems. I’d argue that building lots of infrastructure to abstract away the details of the framework complexly defeats the point. I can’t imagine a situation where I would want to swap out Grails persistence for Play persistence and being able to share the abstracted domain classes is only going to be a small fraction of the cost involved in that swap.

 

Rather than trying to ‘abstract away the framework’ I think about it differently. I’d think about my architecture in a Service Oriented fashion and pick the right framework and infrastructure for each service. If you pick the right service boundaries for you business problem and then pick the right framework for each service you’re going to be in a much better position to use the framework for what its good at and less time building infrastructure for the sake of abstraction.

 

Jon

 

From: Roberto Guerra [mailto:[hidden email]]
Sent: Saturday, August 18, 2012 5:16 PM
To: [hidden email]
Subject: Re: [grails-user] Re: Weak-Ass Domain Objects

 

Yap, sadly so. It is Rails disease that has infected these new web frameworks. 

But you don't have to depend on these domain models. You can create real domain models in separate jars and map them using hibernate or mybatis. And you can use grails just as a 'delivery mechanism'.

You can still apply good design concepts on these frameworks : vimeo.com/43612849

Here is a blog post about an attempt at doing hexagonal architecture on grails: http://stumblingoncode.wordpress.com/2012/07/26/78/

It's just a poc that it can be done.

 

On Sat, Aug 18, 2012 at 2:55 PM, Gary Affonso <[hidden email]> wrote:


On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



 

--
The Journey Is The Reward.



This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Sebastian Gozin
<base href="x-msg://2173/">I wouldn't argue swapping grails persistence for play persistence. I would argue however swapping GORM implementations which as you know are not compatible among one another. As you say building a good service boundary will help you avoid the dependency problem. That suggests you moved your business logic out of your "grails" domain objects and into your "grails" service objects.

Personally I think the names domain and service are wholly misinterpreted by frameworks such as grails.
The service objects look like domain objects to me. While the domain objects look like persistence artifacts.

I can't imagine this is what people originally intended them to be. But what's done is done.
If frameworks insist on making the database the central layer of abstraction, even through the guise of Hibernate, JPA or GORM then to achieve true productivity we must abstract it out so it can no longer dominate the rest of the application.
And we may finally be free of frustrations born from grails being unable to reload persistence artifacts consistently.

- Sebastian


On 19 Aug 2012, at 14:34, Jon Palmer wrote:

I feel like this misses the point a little about ‘rapid development’ frameworks like Grails. One of the core ideas is to have the framework remove the boiler plate code, give you convention over configuration and allow you to have less code better focused on actually solving your business problems. I’d argue that building lots of infrastructure to abstract away the details of the framework complexly defeats the point. I can’t imagine a situation where I would want to swap out Grails persistence for Play persistence and being able to share the abstracted domain classes is only going to be a small fraction of the cost involved in that swap.
 
Rather than trying to ‘abstract away the framework’ I think about it differently. I’d think about my architecture in a Service Oriented fashion and pick the right framework and infrastructure for each service. If you pick the right service boundaries for you business problem and then pick the right framework for each service you’re going to be in a much better position to use the framework for what its good at and less time building infrastructure for the sake of abstraction.
 
Jon
 
From: Roberto Guerra [mailto:[hidden email]] 
Sent: Saturday, August 18, 2012 5:16 PM
To: [hidden email]
Subject: Re: [grails-user] Re: Weak-Ass Domain Objects
 
Yap, sadly so. It is Rails disease that has infected these new web frameworks. 
But you don't have to depend on these domain models. You can create real domain models in separate jars and map them using hibernate or mybatis. And you can use grails just as a 'delivery mechanism'.
You can still apply good design concepts on these frameworks : vimeo.com/43612849
Here is a blog post about an attempt at doing hexagonal architecture on grails: http://stumblingoncode.wordpress.com/2012/07/26/78/
It's just a poc that it can be done.
 
On Sat, Aug 18, 2012 at 2:55 PM, Gary Affonso <[hidden email]> wrote:


On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



 
-- 
The Journey Is The Reward.


This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.




Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Roberto Guerra
I agree with most of what Sebastian has said. Even sectors of the rails community has started to be vocal about using a better 'architecture' and the importance of abstraction. We still need to use solid OO Design principles when building applications, independent of the framework we use to deliver those applications.

Here is a recent presentation related to this same idea: http://programme.scottishrubyconference.com/proposals/105/video


Some benefits of abstracting your application:
1. Smoother upgrades.
2. You can swap delivery mechanisms(aka web frameworks) easier.
3. You can swap up persistence layer easier(postgresql/mysql/watever dbms != persistence layer).

Now, convention over configuration is not an enemy for these types of applications. The thing is, no framework has been developed to make building applications with this architecture yet. Just like before rails building apps the way we do now with grails/django/rails was never thought about. It can currently be done with grails, but its a little painful, it can be easier.

The more applications are built with grails and are put out there, building them the way we do now will cause problems. They will become a huge pile of mud that will not 'scale'. Remember twitter? Then people will cry out: oh, grails doesn't scale, rails doesn't scale, django doesn't scale, play doesn't scale......
When it is not the frameworks fault, but the developers that never thought about proper architecture, design principles and abstraction.

On Sun, Aug 19, 2012 at 6:54 AM, Sebastian Gozin <[hidden email]> wrote:
I wouldn't argue swapping grails persistence for play persistence. I would argue however swapping GORM implementations which as you know are not compatible among one another. As you say building a good service boundary will help you avoid the dependency problem. That suggests you moved your business logic out of your "grails" domain objects and into your "grails" service objects.

Personally I think the names domain and service are wholly misinterpreted by frameworks such as grails.
The service objects look like domain objects to me. While the domain objects look like persistence artifacts.

I can't imagine this is what people originally intended them to be. But what's done is done.
If frameworks insist on making the database the central layer of abstraction, even through the guise of Hibernate, JPA or GORM then to achieve true productivity we must abstract it out so it can no longer dominate the rest of the application.
And we may finally be free of frustrations born from grails being unable to reload persistence artifacts consistently.

- Sebastian


On 19 Aug 2012, at 14:34, Jon Palmer wrote:

I feel like this misses the point a little about ‘rapid development’ frameworks like Grails. One of the core ideas is to have the framework remove the boiler plate code, give you convention over configuration and allow you to have less code better focused on actually solving your business problems. I’d argue that building lots of infrastructure to abstract away the details of the framework complexly defeats the point. I can’t imagine a situation where I would want to swap out Grails persistence for Play persistence and being able to share the abstracted domain classes is only going to be a small fraction of the cost involved in that swap.
 
Rather than trying to ‘abstract away the framework’ I think about it differently. I’d think about my architecture in a Service Oriented fashion and pick the right framework and infrastructure for each service. If you pick the right service boundaries for you business problem and then pick the right framework for each service you’re going to be in a much better position to use the framework for what its good at and less time building infrastructure for the sake of abstraction.
 
Jon
 
From: Roberto Guerra [mailto:[hidden email]] 
Sent: Saturday, August 18, 2012 5:16 PM
To: [hidden email]
Subject: Re: [grails-user] Re: Weak-Ass Domain Objects
 
Yap, sadly so. It is Rails disease that has infected these new web frameworks. 
But you don't have to depend on these domain models. You can create real domain models in separate jars and map them using hibernate or mybatis. And you can use grails just as a 'delivery mechanism'.
You can still apply good design concepts on these frameworks : vimeo.com/43612849
Here is a blog post about an attempt at doing hexagonal architecture on grails: http://stumblingoncode.wordpress.com/2012/07/26/78/
It's just a poc that it can be done.
 
On Sat, Aug 18, 2012 at 2:55 PM, Gary Affonso <[hidden email]> wrote:


On Aug 18, 2012, at 3:31 AM, Sebastian Gozin wrote:

> Also a little bit of advice.
> Gorm objects are not domain objects. They are database artifacts.

Er…

I'm confused.  Do you mean that the objects that I use to model my domain (and that reside in the Grails' "Domain Classes" folder) are not really Fowler-ish "domain objects" but instead a special-case object called a "database artifact"?

Meaning that I should not be expecting to model my domain and it's *behavior* with them, but instead just consider them more like a DTO on steroids?

Can you please clarify?

Thanks!

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



 
-- 
The Journey Is The Reward.


This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.







--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

basejump (Josh)
In reply to this post by Sebastian Gozin
I find that 90% of the time GORM is just fine for the Domain modeling but perhaps I am missing something.

Does anyone have a good example with code showing how a GORM domain model is anemic or flawed from an OOP purist's view?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

Roberto Guerra
It can easily have it violate the SRP.

For example, in grails if you have a 'domain model' Person, you can do:

personInstance.save()
and in some cases personInstance.addChild(childInstance).

The domain model is doing 2 things: persistence and also leaks into the business model. 

Instead, I would like to see:

pesonInstance.addChild(childInstance)
repository.persist(personInstance)

The domain logic and the persistence logic are separate.

On Sun, Aug 19, 2012 at 8:04 AM, Josh (basejump) <[hidden email]> wrote:
I find that 90% of the time GORM is just fine for the Domain modeling but perhaps I am missing something.

Does anyone have a good example with code showing how a GORM domain model is anemic or flawed from an OOP purist's view?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|

Re: Weak-Ass Domain Objects

basejump (Josh)
Well that I disagree with. I would rather configure my app or domain so it knows how to save it self. I might want the person to go to mongo and the others to go to mysql. If the repository is saving other domains in my business logic then I have to go in and create a special repository now?

Regardless this is minor and gorm can be easily be tweaked to pull off your example. 

Ive seen these topic before and have seen a lot of theoretical discussions but what I would like see, and have not yet, is a real life pragmatic example (not some edge case) on why the gorm domains fall short, must be anemic and /or why they are not acceptable for best practice OOP Business model design. 

Sent from my iPhone, please forgive any errors.

On Aug 19, 2012, at 9:12 AM, Roberto Guerra <[hidden email]> wrote:

It can easily have it violate the SRP.

For example, in grails if you have a 'domain model' Person, you can do:

personInstance.save()
and in some cases personInstance.addChild(childInstance).

The domain model is doing 2 things: persistence and also leaks into the business model. 

Instead, I would like to see:

pesonInstance.addChild(childInstance)
repository.persist(personInstance)

The domain logic and the persistence logic are separate.

On Sun, Aug 19, 2012 at 8:04 AM, Josh (basejump) <[hidden email]> wrote:
I find that 90% of the time GORM is just fine for the Domain modeling but perhaps I am missing something.

Does anyone have a good example with code showing how a GORM domain model is anemic or flawed from an OOP purist's view?
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
The Journey Is The Reward.
123