just a few quick observations. On Thu, Sep 3, 2015 at 7:22 PM, Jeroen van der Wal <[email protected]> wrote:
> 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. > > 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 < > > [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? > > 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 >
