isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Cameron <steve.cameron...@gmail.com>
Subject Re: Datanucleus issues
Date Thu, 03 Sep 2015 10:55:24 GMT
just a few quick observations.

On Thu, Sep 3, 2015 at 7:22 PM, Jeroen van der Wal <jeroen@stromboli.it>
wrote:

> 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.
>
> Hmm, contributions rings a bell
http://docs.netkernel.org/book/view/book:quickstart/doc:quickstart:three-cs


>
> > 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?
>
> To be honest I don't know! I guess its more SOA than OO?


> 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