http://www.geeks.ltd.uk/…/Service-Object-

For instance, in an SOA there is a persistence service to which you send entities (entities are objects without behaviour); rather than calling myCustomer.Save() you would call your persistence service and pass in myCustomerEntity as a parameter.

SOA is a different way of thinking about systems. In order to migrate my thinking from OO to SO, I started by introducing a facade for each layer. The only way I could interact with a layer was through the facade. So, instead of doing:

new BL.Customer().GetById(id);

I would call:

BL.Facade.GetCustomerById(id);

This morphed my BL layer, for all intents and purposes, to a service. From there, things sort of came along by themselves.

In a general view, an SOA has a coarse grained Business service which replaces the Domain Model pattern in an OOA. The Business service uses a business rules service/engine for determining whether actions can be performed. Rules include things like DoesOrderQualifyForADiscount(Order o).

In many cases it also makes sense to have a validation service for lower level checks. The lowest level checks, nullability and string lengths for example, can be implemented in the entities themselves.

I find SOAs to be more suited for today’s development challenges than OOAs since they allow for an increased separation of concerns in systems.