Hi Stephen, See inline:
On 3 September 2015 at 07:23, Stephen Cameron <[email protected]> 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 < > [email protected]> > 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
