Limit your abstractionsApplication Events–the wrong way
In my previous post, I have taken a few interfaces from a DDD sample application and called the application procedural and hard to maintain. In this post, I want to show you exactly why.
We will start with examining this interface, and how it is used:
public class CargoInspectionServiceImpl : ICargoInspectionService { // code redacted for simplicity public override void InspectCargo(TrackingId trackingId) { Validate.NotNull(trackingId, "Tracking ID is required"); Cargo cargo = cargoRepository.Find(trackingId); if (cargo == null) { logger.Warn("Can't inspect non-existing cargo " + trackingId); return; } HandlingHistory handlingHistory = handlingEventRepository.LookupHandlingHistoryOfCargo(trackingId); cargo.DeriveDeliveryProgress(handlingHistory); if (cargo.Delivery.Misdirected) { applicationEvents.CargoWasMisdirected(cargo); } if (cargo.Delivery.UnloadedAtDestination) { applicationEvents.CargoHasArrived(cargo); } cargoRepository.Store(cargo); } }
Can you see what I find painful in this code?
More posts in "Limit your abstractions" series:
- (22 Feb 2012) And how do you handle testing?
- (21 Feb 2012) The key is in the infrastructure…
- (20 Feb 2012) Refactoring toward reduced abstractions
- (16 Feb 2012) So what is the whole big deal about?
- (15 Feb 2012) All cookies looks the same to the cookie cutter
- (14 Feb 2012) Commands vs. Tasks, did you forget the workflow?
- (13 Feb 2012) You only get six to a dozen in the entire app
- (10 Feb 2012) Application Events–event processing and RX
- (09 Feb 2012) Application Events–Proposed Solution #2–Cohesion
- (07 Feb 2012) Application Events–Proposed Solution #1
- (06 Feb 2012) Application Events–what about change?
- (03 Feb 2012) Application Events–the wrong way
- (02 Feb 2012) Analyzing a DDD application

Comments
Comment preview