On 17 February 2015 at 08:46, <[email protected]> wrote:
>
>
> Having that available one would have the possibility to create a (nearly)
> fully functional Isis-Application out of the UML-Model.
> The only thing I see (that's why "neraly") is that all behavior which is
> usually done by coding - for example the
> validateXXX - methods - has to be extracted into an extra-class named
> "BehaviourXXX" where all
> the code goes which is *not* generated.
>
> Modeling behavior ( i.e. all that whiles, fors, if then elses) by uml is a
> nightmare
Agreed.
> Isis could do it by looking if a "BehaviourXXX" class exists as a sibling
> of "XXX" class and do an automatic delegation.
> By Using jdk 8 it may be an option to "inject" the behavior into XXX too.
>
>
Actually, Isis does support this using:
- contributions (contributed actions/collections/properties) [1] and also
- subscribers [2],[3],[4] on the event bus [5].
So it would be possible to have the domain entities hold only the structure
("know-what"), and externalize all behaviour into contributions and
subscribers ("know-how-to").
> Of course that's a little bit against the "philosophy" of Isis and leaves
> the path of simplicity which is of very high value
> in my regards.
>
>
I think there's a time and a place for it; it's a spectrum. Isis is
flexible enough to support either approach.
The important thing to ensure is that the codebase is decoupled in line
with the single responsibiliity principle: code that changes at the same
rate can be bundled together, otherwise it should be split apart. That
applies both to classes within a module and also to the structure/behaviour
of a single class.
If an entity's structure and behaviour tends to change at the same rate,
then follow the original "behaviourally complete" idea, and implement the
actions/validation as regular methods on the entity.
If an entity's structure is fairly static but the behaviour changes more
often, then factor out that behaviour into contributions and subscribers.
Note that this second approach is the rationale behind CQRS... separating
out commands (behaviour) from queries. Of course, they then tend to take
it to another level again which is to separate out the datastores both for
each module (which they generally incorrectly call a bounded context)
and/or separate out the datastores for the query vs the commands. I think
that is over-engineered for the use cases where Isis fits. But even so,
the general concept of splitting out code that changes at different rates
is sound.
HTH
Dan
[1]
http://isis.apache.org/more-advanced-topics/how-to-01-062-How-to-decouple-dependencies-using-contributions.html
[2]
http://isis.apache.org/reference/recognized-annotations/ActionInteraction.html
[3]
http://isis.apache.org/reference/recognized-annotations/CollectionInteraction.html
[4]
http://isis.apache.org/reference/recognized-annotations/PropertyInteraction.html
[5] http://isis.apache.org/reference/services/event-bus-service.html
>
> Augustinus
>
> Sorry for just exchanging ideas and no code ;-)
>
