--- In [email protected], [EMAIL PROTECTED] wrote: > > Hi Kirstan, > > I have a problem with such implementation.
Pete, I'm not quite clear on what implementation you are referring to. Is this the example that Colin K posted? Just to be certain, here's his example problem description and a partitioning of processing responsibilities into services, which in his mind (and I agree) seems consistent with Erl's taxonomy of services. ------------- Colin K's sample below -------------------- Here's my understanding of how one might use these. Scenario is cancellation of an auto insurance policy prior to the renewal due date, and the steps at a high level are: a) cancelling the policy b) calculating a premium refund c) paying the refund to the insured party I would propose the following services: * a Policy entity service with have a capability (Erl-speak for a method) 'cancel' which will check that the policy is currently in a valid state to be cancelled (e.g. correct status, premium payments up to date etc) and then set its status to 'cancelled'. [I would contrast this with my interpretation of a 'data service' which would probably just have a 'setStatus' method and assume the caller knows when it's ok to set the status to the requested value] * a Rate entity service with capability calculateRefund() which calculates the refund based on policy information eg # of days left on policy * a customer entity service with capability getBankingDetails() - this is a pure read .. * a Payment task service which facilitates the process of effecting a payment, including any human approvals that may be needed. and * a Cancellation task service which orchestrates all of the above to effect policy cancellation. ^^^^^^^^^^^^^ end Colin K's sample ^^^^^^^^^^^^^^ -Kirstan
