You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by David Tildesley <da...@yahoo.co.nz> on 2015/11/15 21:30:01 UTC
Does ISIS make following "rich domain model" pattern easier?
Hi All,
I am looking for reasons why Apache ISIS framework promotes and enables a "rich domain model" [1] [2] and therefore promotes OO design.
And of course any reasons to the contrary (i.e. things that ISIS does that gets in the way of OO design).
Or is it simply neutral? i.e. developer choice.
Regards,
David.
[1] https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
[2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
Re: Does ISIS make following "rich domain model" pattern easier?
Posted by David Tildesley <da...@yahoo.co.nz>.
Thanks Dan for this comprehensive reply.
Regards,David.
On Monday, 16 November 2015 8:48 PM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
On 15 November 2015 at 20:30, David Tildesley <da...@yahoo.co.nz> wrote:
Hi All,
I am looking for reasons why Apache ISIS framework promotes and enables a "rich domain model" [1] [2] and therefore promotes OO design.
It certainly _enables_ a rich domain model, whereas many other frameworks don't even do that. And its architecture acts a little like a "firewall", preventing behaviour from leaching out of the domain layer and into the adjacent presentation layer and persistence layer, ie technical infrastructure layers that should have no business logic.
I don't know that it necessarily promotes OO (non-anaemic) design, or rather, you can choose to do that or you can choose not to. Generally it's easier to start with a non-anaemic approach - just put behaviour into actions on methods - so in the sense that that is the quickest route to a functioning app, then I suppose it does promote OO.
However, the more I work with the naked objects pattern the more I think of it as an aspect-oriented system rather than an object-oriented one. We are all used to AOP at the technical infrastructure level, for example security (authorization), logging/auditing, command profiling ... and these are all supported by the framework. Also, persistence is another cross-cutting concern which the framework offloads to the DataNucleus ORM. But I also think of naked objects pattern itself as a cross-cutting concern... basically the ability for provide a representation of domain objects in the presentation layer.
Over and above AOP at the technical layer, I think that the framework also promotes aspect-orientation within the domain layer itself. For example, for a long time we've had the concept of contributed actions, which is behaviour implemented in domain services but which apparently belongs to the domain objects (binding on action parameter types). Over the last couple of years the framework has extended this to contributed collections and contributed properties. In the most recent 1.10.0 release we've simplified this with the new @Mixin annotation ... so these things are very much like AOP traits. I experimented with this concept while implementing the incode-module-notes and incode-module-commchannel modules [3], so one can see what such code looks like. I've also used it for some new functionality to be able to generate XML and XSDs from JAXB-annotated "DTO" view models [4]
Also (and I only actually realized this while drafting this answer) the events that we emit on the event bus (for hide/disable/validate/pre-execute/post-execute) are actually a type of pointcut, allowing other behaviour (of the subscribers) to be interleave and influence with the original business logic.
What's important, I think, is not OO design per se. It's that the framework supports the single responsibility pattern, ie that the way to organize code is to put code that changes at the same rate together, but to separate out code that changes at different rates. So sometimes putting behaviour with data is the right thing, but sometimes it's right to move that behaviour out into a mixin or into a subscriber of an event.
And of course any reasons to the contrary (i.e. things that ISIS does that gets in the way of OO design).
No, I don't think it does get in the way of OO design. Though that said there are some minor limitations to the sorts of OO designs one can contemplate... we still don't support collections as action parameters, for example.
Or is it simply neutral? i.e. developer choice.
This is probably the best answer. Though it takes a little time working with the framework to realize this... most will think it is heavily biased to OO and rich domain models and only later realize that one can do it both ways.
My 2c, but would love to hear other opinions on this too.
CheersDan
[3] http://catalog.incode.org/[4] https://github.com/apache/isis/blob/master/core/applib/src/main/java/org/apache/isis/applib/services/jaxb/Dto_downloadXml.java
Regards,
David.
[1] https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
[2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
Re: Does ISIS make following "rich domain model" pattern easier?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 15 November 2015 at 20:30, David Tildesley <da...@yahoo.co.nz> wrote:
> Hi All,
>
> I am looking for reasons why Apache ISIS framework promotes and enables a
> "rich domain model" [1] [2] and therefore promotes OO design.
>
>
It certainly _enables_ a rich domain model, whereas many other frameworks
don't even do that. And its architecture acts a little like a "firewall",
preventing behaviour from leaching out of the domain layer and into the
adjacent presentation layer and persistence layer, ie technical
infrastructure layers that should have no business logic.
I don't know that it necessarily promotes OO (non-anaemic) design, or
rather, you can choose to do that or you can choose not to. Generally it's
easier to start with a non-anaemic approach - just put behaviour into
actions on methods - so in the sense that that is the quickest route to a
functioning app, then I suppose it does promote OO.
However, the more I work with the naked objects pattern the more I think of
it as an aspect-oriented system rather than an object-oriented one. We are
all used to AOP at the technical infrastructure level, for example security
(authorization), logging/auditing, command profiling ... and these are all
supported by the framework. Also, persistence is another cross-cutting
concern which the framework offloads to the DataNucleus ORM. But I also
think of naked objects pattern itself as a cross-cutting concern...
basically the ability for provide a representation of domain objects in the
presentation layer.
Over and above AOP at the technical layer, I think that the framework also
promotes aspect-orientation within the domain layer itself. For example,
for a long time we've had the concept of contributed actions, which is
behaviour implemented in domain services but which apparently belongs to
the domain objects (binding on action parameter types). Over the last
couple of years the framework has extended this to contributed collections
and contributed properties. In the most recent 1.10.0 release we've
simplified this with the new @Mixin annotation ... so these things are very
much like AOP traits. I experimented with this concept while implementing
the incode-module-notes and incode-module-commchannel modules [3], so one
can see what such code looks like. I've also used it for some new
functionality to be able to generate XML and XSDs from JAXB-annotated "DTO"
view models [4]
Also (and I only actually realized this while drafting this answer) the
events that we emit on the event bus (for
hide/disable/validate/pre-execute/post-execute) are actually a type of
pointcut, allowing other behaviour (of the subscribers) to be interleave
and influence with the original business logic.
What's important, I think, is not OO design per se. It's that the
framework supports the single responsibility pattern, ie that the way to
organize code is to put code that changes at the same rate together, but to
separate out code that changes at different rates. So sometimes putting
behaviour with data is the right thing, but sometimes it's right to move
that behaviour out into a mixin or into a subscriber of an event.
> And of course any reasons to the contrary (i.e. things that ISIS does that
> gets in the way of OO design).
>
>
No, I don't think it does get in the way of OO design. Though that said
there are some minor limitations to the sorts of OO designs one can
contemplate... we still don't support collections as action parameters, for
example.
> Or is it simply neutral? i.e. developer choice.
>
>
This is probably the best answer. Though it takes a little time working
with the framework to realize this... most will think it is heavily biased
to OO and rich domain models and only later realize that one can do it both
ways.
My 2c, but would love to hear other opinions on this too.
Cheers
Dan
[3] http://catalog.incode.org/
[4]
https://github.com/apache/isis/blob/master/core/applib/src/main/java/org/apache/isis/applib/services/jaxb/Dto_downloadXml.java
> Regards,
> David.
>
> [1]
> https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
> [2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
>
Re: Does ISIS make following "rich domain model" pattern easier?
Posted by Stephen Cameron <st...@gmail.com>.
Yes, the idea of constraints giving a system specific features (boosting
some, diminishing others) is interesting, the main subject of Roy
Fielding's PhD.
If the essence of DDD is ubiquitous language, then UML definitely adds
nothing because its a distraction when trying to communicate with domain
experts, other graphical tools, like VUE, have more potential I believe. I
once made the mistake of putting an database schema diagram up in a meeting
with a group of scientists, the immediate response of one was to say
"another horrendogram", making a good point with humour I guess.
I will do some experimentation with my alternative approach and report
back, its very encouraging that we are having this discussion though.
On Tue, Nov 17, 2015 at 7:28 AM, David Tildesley <da...@yahoo.co.nz>
wrote:
> Thanks Stephen,
> Certainly the intention of DDD is to make it easier for a development team
> to focus on a "rich domain model" and therefore OO design principles.
> I agree Naked Objects approach facilitates the focusing on the domain
> model as an intention.
> And so both DDD and Naked Objects have the same intention. Another way of
> putting it is that they both strive to remove the "distractions" that
> derail the domain model.
> You could also say the same about UML class model to code intention - the
> intention is to remove the technical "distractions" so that everyone can
> focus on the domain model with the basic use of UML representing the "just
> enough" domain model design.
> One of the main influencers on an efficient and loosely coupled (rich)
> domain model shape is domain behaviour (actual problem domain behaviour -
> beyond the basic setters and getters) e.g. calculateXXX(...).
> Regards,David.
>
>
>
>
> On Monday, 16 November 2015 10:54 AM, Stephen Cameron <
> steve.cameron.62@gmail.com> wrote:
>
>
> Hi David,
>
> I would ask a slightly different question: does Isis assist with DDD as
> explained by Evans as a means of "tackling complexity" (the root of what
> makes big projects fail I believe)?.
>
> In fact its slightly disturbing to me to hear this talk of UML
> "design-time" tools and of round-tripping, that is, if learning by coding
> and refactoring a design (as code) is the essence of 'agile' DDD. In fact
> I spent alot of time looking into this and decided that UML and MDA
> particularly were not that helpful, for that reason. If they were we'd have
> moved to executable UML.
>
> I think a bigger problem is that people use OO when its not actually the
> best kind of language for their specific problem.
>
> To answer your question though, I'd say its the naked objects approach more
> than use of OO per se that aids that, you focus more on the objects than on
> specific use-cases. If that is done an anaemic design seems improbable.
>
> On Mon, Nov 16, 2015 at 7:30 AM, David Tildesley <da...@yahoo.co.nz>
> wrote:
>
> > Hi All,
> >
> > I am looking for reasons why Apache ISIS framework promotes and enables a
> > "rich domain model" [1] [2] and therefore promotes OO design.
> >
>
> > And of course any reasons to the contrary (i.e. things that ISIS does
> that
> > gets in the way of OO design).
> >
> > Or is it simply neutral? i.e. developer choice.
> >
> > Regards,
> > David.
> >
> > [1]
> >
> https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
> > [2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
> >
>
>
>
>
Re: Does ISIS make following "rich domain model" pattern easier?
Posted by David Tildesley <da...@yahoo.co.nz>.
Thanks Stephen,
Certainly the intention of DDD is to make it easier for a development team to focus on a "rich domain model" and therefore OO design principles.
I agree Naked Objects approach facilitates the focusing on the domain model as an intention.
And so both DDD and Naked Objects have the same intention. Another way of putting it is that they both strive to remove the "distractions" that derail the domain model.
You could also say the same about UML class model to code intention - the intention is to remove the technical "distractions" so that everyone can focus on the domain model with the basic use of UML representing the "just enough" domain model design.
One of the main influencers on an efficient and loosely coupled (rich) domain model shape is domain behaviour (actual problem domain behaviour - beyond the basic setters and getters) e.g. calculateXXX(...).
Regards,David.
On Monday, 16 November 2015 10:54 AM, Stephen Cameron <st...@gmail.com> wrote:
Hi David,
I would ask a slightly different question: does Isis assist with DDD as
explained by Evans as a means of "tackling complexity" (the root of what
makes big projects fail I believe)?.
In fact its slightly disturbing to me to hear this talk of UML
"design-time" tools and of round-tripping, that is, if learning by coding
and refactoring a design (as code) is the essence of 'agile' DDD. In fact
I spent alot of time looking into this and decided that UML and MDA
particularly were not that helpful, for that reason. If they were we'd have
moved to executable UML.
I think a bigger problem is that people use OO when its not actually the
best kind of language for their specific problem.
To answer your question though, I'd say its the naked objects approach more
than use of OO per se that aids that, you focus more on the objects than on
specific use-cases. If that is done an anaemic design seems improbable.
On Mon, Nov 16, 2015 at 7:30 AM, David Tildesley <da...@yahoo.co.nz>
wrote:
> Hi All,
>
> I am looking for reasons why Apache ISIS framework promotes and enables a
> "rich domain model" [1] [2] and therefore promotes OO design.
>
> And of course any reasons to the contrary (i.e. things that ISIS does that
> gets in the way of OO design).
>
> Or is it simply neutral? i.e. developer choice.
>
> Regards,
> David.
>
> [1]
> https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
> [2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
>
Re: Does ISIS make following "rich domain model" pattern easier?
Posted by Stephen Cameron <st...@gmail.com>.
Hi David,
I would ask a slightly different question: does Isis assist with DDD as
explained by Evans as a means of "tackling complexity" (the root of what
makes big projects fail I believe)?.
In fact its slightly disturbing to me to hear this talk of UML
"design-time" tools and of round-tripping, that is, if learning by coding
and refactoring a design (as code) is the essence of 'agile' DDD. In fact
I spent alot of time looking into this and decided that UML and MDA
particularly were not that helpful, for that reason. If they were we'd have
moved to executable UML.
I think a bigger problem is that people use OO when its not actually the
best kind of language for their specific problem.
To answer your question though, I'd say its the naked objects approach more
than use of OO per se that aids that, you focus more on the objects than on
specific use-cases. If that is done an anaemic design seems improbable.
On Mon, Nov 16, 2015 at 7:30 AM, David Tildesley <da...@yahoo.co.nz>
wrote:
> Hi All,
>
> I am looking for reasons why Apache ISIS framework promotes and enables a
> "rich domain model" [1] [2] and therefore promotes OO design.
>
> And of course any reasons to the contrary (i.e. things that ISIS does that
> gets in the way of OO design).
>
> Or is it simply neutral? i.e. developer choice.
>
> Regards,
> David.
>
> [1]
> https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
> [2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
>