Cargo tracking web interface now sits immediately on top of the domain layer, forming one of the "user interface extremes" (the other one being complete remote-DTO-separation).
Brought EventService closer to the domain by renaming it DomainEventNotifier and use ubiquitous language in the method signatures (fireHandlingEventRegistered is now cargoWasHandled) in order to make it naturally fit in among the domain services.
Package "remote" renamed "remoting" for consistency.
The implementation of our routing service - which consists mainly of model translation and delegation - is moved to the application part, from the domain service layer. The routing service interface is part of our domain but the implementation is not, similar to repositories and their implementations.
Slight refinement of packge structure under application - service is split into things like messagning and remoting.
The external routing team application is moved out to its own top-level package, to highlight the fact that it is a completely separate application from booking/tracking.
Introduced OR mapping for the Cargo->(DeliveryHistory)->HandlingEvent relation, instead of explicitly deciding whether or not to fetch handling events when loading a particular cargo.
Introduced BookingServiceFacade as an application service, on top of the domain layer's BookingService and the repositories, as a DTO assembly point and remoting exposure layer (currently configured in context-remote.xml, but only used as local reference).
CargoAdminController now sits on top on this facade. If time permits, the booking part of the application can be moved to another virtual machine at this point.