public Bid.BidAggregate PlaceBid(
Port.IDependencies di,
TimeRange pickupTime,
TimeRange dropoffTime,
Money price)
{
return(di.Instance <_PlaceBid>().PlaceBid(
this,
pickupTime,
dropoffTime, price));
}
/// <summary>
/// Alter the pickup location.
///
/// Aggregate methods that have dependencies are implemented as
/// "hidden" (private, nested) Service classes (AlterPickupSvc in
/// this case) and exposed to clients on the Aggregate interface
/// just like this. This method *must* be a pass-through only, with
/// no logic whatsoever.
///
/// We get as much of the best of both words as we can:
/// - Client authors see a concise argument list.
/// - Test authors see dependencies enumerated on the hidden
/// service's constructor.
/// </p>
/// </summary>
/// <param name="di">
/// A dependency injector. Using a thin facade atop what'll be
/// StructureMap at runtime keeps our Domain model pure (entirely
/// lacking in external dependencies) and means that switching DI
/// Containers later doesn't modify the Domain at all.
/// </param>
/// <param name="newPickupAddress">
/// </param>
public void AlterPickup(Port.IDependencies di, string newPickupAddress)
{
di.Instance <_AlterPickup>()
.AlterPickup(this, newPickupAddress);
}
