Thanks Dan. Agree with all your comments and suggestions.
One more hiccup I ran into was the modeling of Schedule[1]. A schedule has
a List of CarrierMovement but the list is immutable by being passed into
the Schedule constructor, having no setter or addTo/removeFrom methods, and
the getter returns a Collections.unmodifiableList wrapping the list.
I have a repository for finding Voyages (which hold a reference to a
Schedule.) When I run the find action in the Wicket viewer I get an
exception:
java.lang.UnsupportedOperationException
at
java.util.Collections$UnmodifiableCollection.remove(Collections.java:1019)
at
org.apache.isis.core.progmodel.facets.collections.modify.CollectionRemoveFromFacetViaAccessor.remove(CollectionRemoveFromFacetViaAccessor.java:76)
at
org.apache.isis.core.runtime.transaction.facets.CollectionRemoveFromFacetWrapTransaction.remove(CollectionRemoveFromFacetWrapTransaction.java:50)
at
org.apache.isis.core.metamodel.specloader.specimpl.OneToManyAssociationImpl.removeElement(OneToManyAssociationImpl.java:180)
at
org.apache.isis.core.runtime.memento.Memento.updateOneToManyAssociation(Memento.java:366)
at
org.apache.isis.core.runtime.memento.Memento.updateField(Memento.java:337)
...
By debugging, I see that my firstMatch query finds the correct Voyage with
the Schedule and CarrierMovements intact. But the above code tries to
iterate over the CarrierMovements collection and remove the elements
throwing the above exception.
Is there something I can do to keep the immutability constraints in place?
Thanks.
--
Adam
[1]:
https://github.com/joolu/ddd-sample/blob/master/src/main/java/se/citerus/dddsample/domain/model/voyage/Schedule.java
On Tue, Feb 5, 2013 at 3:56 PM, Dan Haywood
<d...@haywood-associates.co.uk>wrote:
> On 5 February 2013 20:50, Adam Howard <howard.a...@gmail.com> wrote:
>
> > Hello,
> >
> > I just watched Eric Evans' talk at QCon SF 2012 [1]. It reminded me to
> take
> > another look at the dddsample app [2][3] which models a cargo shipping
> > operation. I'd like to try porting the app to Isis but I've run into a
> few
> > questions about Value Objects:
> >
>
> Good stuff. I've thought about doing this several times, but never managed
> to muster up the enthusiasm. Part of my lack of enthusiasm is down to the
> fact that the online (or at least vocal) DDD community seems somehow to
> have equated DDD with CQRS, has decided that ORMs are the work of the
> devil, and has either forgotten or never knew about isolation levels as the
> usual way of enforcing transactionality semantics.
>
> But even so, while this effort won't bring any of that community over to
> Isis, I do think it'd be rather fun to have our own port. I'd certainly
> enjoy doing a line count comparison.
>
>
>
> > 1. UnLocode[4] is a ValueObject. Basically just a wrapper around a String
> > with some added validation rules. In Isis, I've created the UnLocode
> class,
> > annotated it with @Value and created UnLocodeValueSemanticsProvider and
> > UnLocodeValueFacet implementations.
> >
> > Agreed.
>
> You might be able to move the validation into the @Regex annotation,
> annotated on the type itself, ie:
>
> @Regex("...")
> public class UnLocode { ... }
>
> That said, I'm looking for tests and can't find any, so I guess there's a
> chance that this could be buggy.
>
>
>
> > 2. Location[5] is an Entity. It contains a UnLocode (embedded as a string
> > in JPA speak) and a String for the location name. This is a normal class
> in
> > Isis (possibly extending AbstractDomainObject.) There is a
> > LocationRepository for finding Locations.
> >
>
> Looks simple enough. Strange that they haven't followed JavaBean
> conventions for the two properties. Not surprising is the fact that this
> entity has no behaviour... I suspect it is all in some other layer of the
> app.
>
>
>
> >
> > 3. CarrierMovement[6] is a ValueObject consisting of departure and
> arrival
> > locations and departure and arrival times. BUT, the dddsample app stores
> > instances in their own table in the database[7]. How would this be mapped
> > to Isis concepts? Would it be an AbstractDomainObject but immutable and
> > "sharable?"
> >
>
> I know it claims to be a value object, but I think it is an entity. Why
> would a value object have an id, for goodness sake?
>
> But it is an immutable one... so I agree with your suggestion is correct.
>
>
>
>
> >
> > Any help is appreciated and will get this on github faster :)
> >
>
> Looking forward to seeing it there.
>
> Can I also suggest that when you port the code that you *don't* inherit
> from AbstractDomainObject etc. Having plain pojos makes it more obvious
> that Isis domain classes have a very light coupling (via the injected
> DomainObjectContainer) to the domain.
>
> Cheers
> Dan
>
>
>
> > --
> > Adam
> >
> > [1]: http://www.infoq.com/presentations/CAP-DDD
> > [2]: http://dddsample.sourceforge.net/
> > [3]: https://github.com/joolu/ddd-sample
> > [4]:
> >
> >
> https://github.com/joolu/ddd-sample/blob/master/src/main/java/se/citerus/dddsample/domain/model/location/UnLocode.java
> > [5]:
> >
> >
> https://github.com/joolu/ddd-sample/blob/master/src/main/java/se/citerus/dddsample/domain/model/location/Location.java
> > [6]:
> >
> >
> https://github.com/joolu/ddd-sample/blob/master/src/main/java/se/citerus/dddsample/domain/model/voyage/CarrierMovement.java
> > [7]:
> >
> >
> https://github.com/joolu/ddd-sample/blob/master/src/main/resources/se/citerus/dddsample/infrastructure/persistence/hibernate/CarrierMovement.hbm.xml
> >
>
