You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Stephen Cameron <st...@gmail.com> on 2015/11/15 22:54:24 UTC
Re: Does ISIS make following "rich domain model" pattern easier?
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>.
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
>