This post originated from an RSS feed registered with .NET Buzz
by James Avery.
Original Post: Adventures in SOA, Part 3
Feed Title: .Avery Blog
Feed URL: /blog/Install/BlogNotConfiguredError.aspx
Feed Description: .NET and everything nice
I did not expect to be writing another one of these this soon, but a fellow named Udi Dahan (go subscribe to his blog now, I will wait) left a very good comment on my last post and I wanted to discuss his comments and how I might apply them in my architecture.
He states that the domain model does not really fit in a service oriented architecture, as it was built with OO in mind. He suggests that instead of a more object focused pattern like the domain model, that is should be more service oriented. His example is that instead of calling BL.Customer().GetById(id) you would call BL.Facade.GetCustomerById(id).
This is very familiar to me, as it is very similar to a project I am currently working on. We use business entities with very service like business and persistence methods. This separates the data into separate entities, and puts the business logic in service-like methods instead of on the object. I am not sure what this architecture is buying me though, what benefit does it have over a domain model? In my current project the main benefit is that we can pass business entities across the remoting boundary, and you would not want to pass the business logic along with the entitiy, but since I am against the sharing of types, this benefit does not translate to my architecture.
In an architecture like this you would have a facade or service layer which uses the business entities and a number of service engines to check business rules and persisist data. You might have a service method that saves a customer entity, this method would first call a number of methods on a business rules engine to check the validity of the customer entity. Then the service method would call a method on the persistence engine to save this entity to the database. This is a very intriguing idea, and is actually somewhat different than my current project where we have a more transaction script pattern. (service method -> business method --> persistence method)
Fowler has another name for this, its called the AnemicDomainModel. Fowler describes this as:
"There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is very little behavior on these objects. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data."
Fowler is a large proponent of OOA and appears to have an aversion to this architecture, but that does not mean it is wrong. After all, SOA is supposed to address some of the issues of OOA, and thus you would expect there to be some pretty major differences and that one of the major proponents of OOA might not like this architecture.
So back to my question before, what does this more service oriented model do for me? Well, here are the benefits as I see them.
1) This architecture just makes sense in SOA, at some point in the future these engines which are now being called though method calls could be called through web services. It is this detachment that is a major goal of SOA.
2) Since the business rules are built as services, they can be called from any other section of the current system or future system. This is another major goal of SOA.
3) Simplicity. Instead of large complex objects, you have lightweight data containers and services that perform operations on them.
4) This architecture lends itself to iterative development more than a conventional OO design, additional services can be created without modifying the business entities and breaking current code.
Basically I am starting to see the benefits of building the system in this fashion, so thanks for the suggestion Udi, I think I am going to take it.
Previous Topic
