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. 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 >
