Skip navigation.

Gateways... Services... Providers... No! They're "Business Experts"

patterns

I'm working with a customer that is implementing a website that allows customers to purchase products... This site has to talk to various webservices to obtain information about pricing and delivery options.

They were concerned that they didn't know what the interface for the delivery options web service was going to be so of course, I simply highlighted that this should be abstracted from their system as much as possible. All they new is that for a given order (made up of delivery address and the list of products) delivery options will vary depending on the types of products ordered and the delivery address. Other solutions (such as an internal call-centre package) will also be using the delivery options web service.

I mentioned the Gateway Pattern as starting point for solving the problem... but it seemed to not quite fit with the metaphor for the domain... and then it occurred to me that what they were doing was asking a 'Business Expert' what delivery options were suitable for a given order.

One way of writing this might be (assuming that we have used dependency injection for the deliveryOptionsExpert)...

List< DeliveryOption > deliveryOptions = deliveryOptionsExpert.whatAreTheDeliveryOptionsFor(thisOrder);

Or if you don't like fluent APIs and prefer a more old-school approach...

List< DeliveryOption > deliveryOptions = deliveryOptionsExpert.getDeliveryOptionsFor(thisOrder);

etc... etc...

For now, they can stub out the delivery options expert and when they know what interface the webservice will offer, the WebServiceDeliveryOptionsExpert can implement that detail internally...

You could apply a service locator approach to this where your service locator was simply a BusinessExpert... that knows how to find the appropriate Specialist Business Expert (Such as a DeliveryOptionsExpert) that knows how to answer specific questions...

Nothing new there... just a different way of thinking about the problem... a more domain-driven metaphor and less implementation oriented... They seemed to like it and are giving it a try... thought I'd share it with you.