isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeroen van der Wal <jer...@stromboli.it>
Subject Re: Datanucleus issues
Date Thu, 03 Sep 2015 09:22:56 GMT
Hi Stephen,

See inline:

On 3 September 2015 at 07:23, Stephen Cameron <steve.cameron.62@gmail.com>
wrote:

> I'll take stock before doing any more. I'm just burying myself the way I am
> going.
>
> I have 'Implementing Domain Driven Design' by Vaughn Vernon on my
> bookshelf, I should make use of it (re aggregates). Also, via the Isis
> documentation I've found 'Growing Object Oriented Software Guided by
> Tests', that is the immediate priority, to start using TDD.
>
> I have looked at Estatio but its too different to what I am used to, I need
> more hand-holding, so will work with those books for a week and come back
> to it.
>
These books are good in their own right and will deepen your knowledge
about DDD and TDD. But with Isis and Estatio we took a more pragmatic (or
better?) approach and by the time we've added contributions it has become a
hybrid of paradigms. So you would limit yourself I you're just following
Vaugh Vernon's or Eric Evans' approach.


> On Thu, Sep 3, 2015 at 9:32 AM, Stephen Cameron <
> steve.cameron.62@gmail.com>
> wrote:
>
> > Thanks for your help and I've no disagreement with your frank advice. I
> am
> > on the bottom end of a learning curve, one which I am working hard to
> > climb.
>
No worries, we can also learn from the questions you raise. Because you can
get results with Isis very vast doesn't mean it's rookie-friendly, an area
in which we can improve.


> >
> > Just one question, about the domain service for each domain object, this
> > seems sensible for top-level objects, but isn't it contrary to good OO
> > modelling to do it for every domain object? DDD has the aggregates
> concept,
> > which if I understand means a hierarchy with the top level objects
> managing
> > the lower level ones.
>
>
> > For example in this scenario, it makes sense for an Activity to
> 'register'
> > a Participant and in doing so add a Participation to its participants
> > collection. Having a participation repository domain service just
> confuses
> > this.
>
>
> > Participation at the database level is a join table between Activity and
> > Participant for a many-to-many relationship, but it also holds data.
> >
> > What I haven't done is model this properly in terms of these register and
> > unregister 'messages' (methods) for the Participant to use on Activity,
> > which I will now do, with some tests. But the right pattern to use is
> still
> > unclear.
>
Putting the creation and retrieval of domain objects in a separate class
allows easy mocking in unit tests and limits the scope of integration
tests. This doesn't mean you should move a "register" action to the
Participations service. But using contributed actions you could create a
method like Participations#newParticipation(Participant p, Activity a)
which is visible on both Activity and Participant. Cool hey?

Now a little more practical: given we have an Invoice (=aggregate root) and
InvoiceItem we typically end up with these files:

[dom] src/main/java/dom/invoice/Invoice.java -> Domain Object
[dom] src/test/java/dom/invoice/InvoiceTest.java -> Unit tests for actions
on domain objects
[dom] src/main/java/dom/invoice/Invoices.java -> Domain Service, factory
and repository for Invoice
[dom] src/test/java/dom/invoice/InvoicesTest.java -> Unit tests,
interaction with DomainObjectContainer is mocked
[integtest] src/test/java/integtests/invoice/InvoicesTest -> Integration
tests, check if data is persisted correctly

[dom] src/main/java/dom/invoice/InvoiceItem.java -> Domain Object
[dom] src/test/java/dom/invoice/InvoiceItemTest.java -> Unit tests for
actions on domain objects
[dom] src/main/java/dom/invoice/InvoiceItems.java -> Domain Service,
factory and repository for Invoice
[dom] src/test/java/dom/invoice/InvoiceItemsTest.java -> Unit tests,
interaction with DomainObjectContainer is mocked
[integtest] src/test/java/integtests/invoice/InvoiceItemsTest ->
Integration tests, check if data is persisted correctly

[fixture]
src/main/java/fixture/invoice/InvoiceForCustomerAcmeWithAllProductsSelected.java
-> A scenario you want to use in an integration test or for demonstration
purposes.

HTH

Jeroen

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message