Re: Thinking about re-introducing UML in our workflow

[David Tildesley]

On Sunday, 15 November 2015 5:37 AM, Dan Haywood 
 wrote:
> Thanks for this James.

> My observation re: using the (relational) data model as the initial input
> though is that this is likely to lead to rather coupled code, ultimately
> not maintainable.

Couldn't agree more.


> So, while going from the database up to the domain is fine for a single
> module of 10 or so entities, any app that is bigger than this really should
> be modelled from the domain down to the database.

Quite right. Any business app that is non trivial should be domain modelled.

David.

> Dan





On 14 November 2015 at 15:00, James Agada  wrote:

> I actually tested out using Telosys to generate an isis app from database
> definition. It did work but of course it meant i did the ER first. I used
> MySQL, did the ER modelling on the workbench, forward engineered into the
> database and then used telosys scripts to generate a functional Isis
> application. Did it as a PoC but we will come back to it later.
> James Agada
> Chief Technology Officer
>
>
> On 14 Nov 2015, at 3:49 PM, Óscar Bou - GOVERTIS 
> wrote:
>
> Many thanks, Stephen for this detailed explanation.
>
> The problem I’m facing is that I intent to communicate the developers
> what’s the model to implement.
>
> And I usually don’t find big mistakes in action code, but what mostly
> forces us to refactor is miscommunication regarding the Domain Entities,
> attributes and actions names, including typos  (think my team speak Spanish
> but they’re modeling in English) or wrong or missing relationships between
> those entities.
>
> All that could be avoided by firstly agree in a common UML Class Diagram.
>
> If it can potentially generate automatically the Java skeleton with Apache
> Isis annotations is a big plus, as it will avoid mistakes when moving from
> design to implementation.
>
> And if it could potentially reverse engineer Java (incl. Apache Isis
> idioms) a really good feature.
>
> Any ideas about what tools could best adapt to the workflow (that could be
> potentially customized to cover the last 2 whishes) ?
>
>
> Thanks,
>
> Oscar
>
>
>
>
> El 14 nov 2015, a las 2:03, Stephen Cameron 
> escribió:
>
> Hi Oscar,
>
> In a qualified way I think your idea has merit. I have never used UML for
> design, but a few years ago I decided to take a good look at it and see it
> if was useful. The idea of being able to draw a diagram and generate code
> from it seemed sensible, after all that is what is done by most other
> 'design' professions, such as building architects and engineers.
>
> To cut a long story short I realised after some reading that it was not
> that simple, and that OO languages themselves are really all that are
> needed for the process of designing a system. This is "the code is the
> design" school of thought, mainly attributed to Jack Reeves [1].
>
> I found that  keeping code and UML diagrams in sync in a top-down 'UML to
> code' design process will always be problematic (maybe why there are
> apparently no open-source tools that claim to do this). Then I read about
> Domain Driven Design which seemed to agree with this premise, and from
> there found Apache Isis via Dan's  book.
>
> So now for me UML class diagrams do have an after the fact use for
> documentation purposes and if a solution implement was capable of that
> reverse generation of diagrams from code it would be a good thing to have.
> Entity Framework can do this, its their "code first" approach.
>
> Given that the-code-is-the-design is true, I think that UML class diagrams
> real main value is as a data model, the question then is why not use a
> purely data-modeling tool and generate Java classes off it. Then the
> diagrams 'designed' could have a usefulness to programmers and to system
> users, something like those created SchemaSpy [2]  for example.
>
> There are already useful and free Java class generation (binding) tools
> from off data-models, of one sort or another, such as JAXB, DataNucleus'
> schemaGen[3], even CAM [4].
>
> Here is my vision of what I think would be really useful: to have a design
> tool that can be used by non-programmers to create a simple data-model, and
> then to have that create a working Apache Isis based CRUD system. This
> could serve your purpose (I guess) and also find a wider use.
>
> The means of achieving this would I think, require something like the
> "dynamic classes" in available in the Moxy framework [5], that is, map
> based so that no Java class compilation is needed. Instead, a data-model
> configuration file (a schema) is read-in to configure the system. This is
> not a strange idea, in fact its the data-driven programming paradigm that
> is the basis of the original browser concept (before it was turned into OO
> application framework via addition of Javascript). In the browser the data
> is HTML that is turned into an 

Does ISIS make following "rich domain model" pattern easier?

[David Tildesley]

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: Thinking about re-introducing UML in our workflow

[Jeroen van der Wal]

All very interesting!

Over the years I tried numerous modelling tools and only the low-tech ones
stayed: drawing on a whiteboard, using coloured index cards [1] (learned
from Dan) or using a simple online tool like yUML [2]. And I only use them
to communicate the broad picture or for explorative purposes.

I gave up on code generators: I always ended up fighting the generated
code. And the impression that they support rapid application development
proved wrong: at the point where you had to work on more advanced stuff
velocity came to a halt. If an application is built on lots of repeating
code snippets then my conclusion is that the underlying framework is not
good enough.

I love source code that tells the story of the application. Where
everything that could be left out of the code is eliminated. Very DRY,
convention over code. This has drawn me to Naked Objects and made me decide
to spend my time on Apache Isis.

As you imagine by now I would not take the route from diagram to code. For
me the code editor is the sole canvas to express your ideas. And I think
that if we keep improving Apache Isis on a few points there will never be a
need for an additional tool:

1) Reduce boilerplate and make writing an application skeleton as easy as
the easiest modelling tool. This has the advantage that a software
architect can sketch the application and leave it to his developers to fill
in details. But everyone is working on the same code base using the same
tools. In this area we started using Lombok. Also Dan had an idea to make
it possible to create your own custom annotations which can combine
multiple annotations.

2) Visualise the meta model. With contributions and mixins the application
logic can come from anywhere. This is architecturally sane but makes an
application hard to grasp. It would love to see a maven plugin that
generates appealing documentation from the meta model of an Isis
application.

3) When taking the visualisation concept a bit further it would be very
powerful to explore and navigate the meta model within the IDE. Any plugin
developers here?

That's just my two cents.

Cheers,

Jeroen


On 15 November 2015 at 21:01, David Tildesley  wrote:

>
>
>
>
>
> On Sunday, 15 November 2015 5:37 AM, Dan Haywood <
> d...@haywood-associates.co.uk> wrote:
> > Thanks for this James.
>
> > My observation re: using the (relational) data model as the initial input
> > though is that this is likely to lead to rather coupled code, ultimately
> > not maintainable.
>
> Couldn't agree more.
>
>
> > So, while going from the database up to the domain is fine for a single
> > module of 10 or so entities, any app that is bigger than this really
> should
> > be modelled from the domain down to the database.
>
> Quite right. Any business app that is non trivial should be domain
> modelled.
>
> David.
>
> > Dan
>
>
>
>
>
> On 14 November 2015 at 15:00, James Agada  wrote:
>
> > I actually tested out using Telosys to generate an isis app from database
> > definition. It did work but of course it meant i did the ER first. I used
> > MySQL, did the ER modelling on the workbench, forward engineered into the
> > database and then used telosys scripts to generate a functional Isis
> > application. Did it as a PoC but we will come back to it later.
> > James Agada
> > Chief Technology Officer
> >
> >
> > On 14 Nov 2015, at 3:49 PM, Óscar Bou - GOVERTIS 
> > wrote:
> >
> > Many thanks, Stephen for this detailed explanation.
> >
> > The problem I’m facing is that I intent to communicate the developers
> > what’s the model to implement.
> >
> > And I usually don’t find big mistakes in action code, but what mostly
> > forces us to refactor is miscommunication regarding the Domain Entities,
> > attributes and actions names, including typos  (think my team speak
> Spanish
> > but they’re modeling in English) or wrong or missing relationships
> between
> > those entities.
> >
> > All that could be avoided by firstly agree in a common UML Class Diagram.
> >
> > If it can potentially generate automatically the Java skeleton with
> Apache
> > Isis annotations is a big plus, as it will avoid mistakes when moving
> from
> > design to implementation.
> >
> > And if it could potentially reverse engineer Java (incl. Apache Isis
> > idioms) a really good feature.
> >
> > Any ideas about what tools could best adapt to the workflow (that could
> be
> > potentially customized to cover the last 2 whishes) ?
> >
> >
> > Thanks,
> >
> > Oscar
> >
> >
> >
> >
> > El 14 nov 2015, a las 2:03, Stephen Cameron 
> > escribió:
> >
> > Hi Oscar,
> >
> > In a qualified way I think your idea has merit. I have never used UML for
> > design, but a few years ago I decided to take a good look at it and see
> it
> > if was useful. The idea of being able to draw a diagram and generate code
> > from it seemed sensible, after all that is what is done by most other
> > 

Re: Does ISIS make following "rich domain model" pattern easier?

[Stephen Cameron]

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

[Dan Haywood]

On 15 November 2015 at 20:30, David Tildesley  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
>