Udi,
I agree with your comments. The purpose of my example was to illustrate
how to handle transactions in a loosely coupled manner and I didn't
think to much about where to implement the business rules, but the
question is very interesting.
My preferred way to organize business rules are to organize them around
the central object in the rule. The purpose of this organization is to
make it easy to find the specifications of the business rule. The next
question is where to implement the rule. If possible, I prefer to
implement the business rule in the service that has the responsibility
for the object that is the central object in the business rule.
In my example the business rule would be "Customer that places an Order
above $$$ SHALL be promoted to gold customers". The central object is
the Customer and hence the business rule should be implemented in the
Customer Service. I agree that the Order Service should publish an
OrderAccepted event, but my first choice would be to have the Customer
Service subscribe to this event. The Order Service still needs to
subscribe to the Customer Service to handle autonomy, performance and
references (e.g. if a customer is removed).
If the business rule for Customer Status Logic is more complex it may be
necessary to enforce it outside the Customer Service, e.g. in the
business process that handles the order-to-cash process, which would be
similar to your proposal.
// Dennis Djenfer
Udi Dahan wrote:
Dennis,
> when the Order Service receives a message with an order that is above
a certain value, it will send a message to a queue that the Customer
has a new status.
While that may seem reasonable in this specific example, customer
status logic often is much more involved. As such, putting that in the
Order Service seems suspect. Orders could alternatively publish an
OrderAccepted event -- to which the CRM subscribes. As that event
arrives, and the CRM does its logic, it in turn could publish a
CustomerStatusChanged event. This would avoid the cross-service
transaction issue.
> the Order Service has a cache of Customer data.
That may be necessary for Orders autonomy (ability to accept orders
even if CRM momentarily unavailable), yet should not change the
allocation of responsibility for business rules.
--
Udi Dahan - The Software Simplist
*From:* [email protected]
[mailto:[EMAIL PROTECTED] *On Behalf Of
*Dennis Djenfer
*Sent:* 19 September 2008 02:59
*To:* [email protected]
*Subject:* Re: [service-orientated-architecture] Re: SOA over a Domain
Model
Colin,
I didn't say that I find updates to multiple (entity) services rare.
What I sad was "Updates to multiple services in one work unit is
something that I try to avoid. Usually it is not necessary". Your
example with an Order Service and a Customer Service where an Order
over a certain value would promote a Silver Customer to a Gold
Customer is a good example. There are many ways to solve this problem,
but you need to define the business rule somewhere and then you need
to enforce it, either in the same place as it's defined or somewhere
else. Lets say that the above business rule is enforced by the Order
Service (but it could also be enforced by a service in a higher layer
or by the the order-to-cash process).
Do we need to update both the Order Service and the Customer Service
as one unit? It depends, but in most cases I don't think it's
important that the Customer gets updated with the new status promptly.
Hence, when the Order Service receives a message with an order that is
above a ceratin value, it will send a message to a queue that the
Customer has a new status. The queue manager will eventually deliver
the message to the Customer Service. If the queue manager should fail
(which happens very rarely) there must be routines in place to handle
this. It could involve manual routines.
How does the Order Service know that the Customer should be updated
with a new status? Because the Order Service has a cache of Customer
data. The Customer Services publishes information about changes that
other services and applications could be interested in. The Order
Service subscribes to this information.
// Dennis Djenfer
Colin Jack wrote:
One of these services would probably be a Customer Service. In the
modeling effort we would identify the core properties of the
Customer object, and other objects that are related to the Customer
and belongs to the same Service. This core set of properties would
be the first version of the Specification of the Customer Service.
However, it would be the demand for customer information in
strategic processes that would be the trigger to actually go ahead
and build the Customer Service.
I think I understand now, seems like you have a more lightweight and
more flexible alternative to what Erl is suggesting.
I was however surprised in your other post when you said that you find
updates to multiple (entity) services are rare though, I'd have
thought it happens relatively regularly. For example if a pending
credit check fails we will update the credit check itself and probably
the related Customer, likewise if the Customer places (and pays for) a
large Order we might update the Customer to indicate they should get
special treatment. In both cases you've probably got two entities (or
two entity services) being updated in one "transaction", how do you
manage this?
<
o:p>
-Colin Jack
------------------------------------
Yahoo! Groups Links
http://groups.yahoo.com/group/service-orientated-architecture/
Individual Email | Traditional
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
http://docs.yahoo.com/info/terms/
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.7.0/1679 - Release Date: 2008-09-18
17:03
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.21/1672 - Release Date:
18/09/2008 17:03
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.7.0/1682 - Release Date: 2008-09-20 10:24
