Thanks Dan for this comprehensive reply.
Regards,David.
On Monday, 16 November 2015 8:48 PM, Dan Haywood
<[email protected]> wrote:
On 15 November 2015 at 20:30, David Tildesley <[email protected]> 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
