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
>
