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.
Until next time….
-James
{ 4 comments }
James,
Thanks for the compliments ! But there are some things that I’d like to set straight. I hold Martin Fowler in seriously high regard. I have learned a lot from him, and continue to do so. I’ve just become a little disillusioned about OO architecture.
Why ?
Because of the "Where does this go ?" syndrome. This syndrome attacks after you’ve already built quite a lot of the system, and usually takes the form of some method you need to add, but just don’t know to which object.
For example, I do a lot of systems for academic institutions, and the following requirement sums it up: A lab administrator registers a student to a final project, for a course that the student is registered to in the given semester.
From this I know I need a "RegisterStudentToFinalProjectForCourseAndSemester(Student s, Project p, Course c, Semester r)" method. But where does it go ? On the LabAdmin class ? The Student ? Project ? Course ? Semester ? Eventually I just pick one and moved on.
What’s the problem with this ?
Well, the class that I choose becames tightly coupled to all the other classes. Martin Fowler probably would have found a nice solution using aspects ( as Brian McCallister posted here: http://kasparov.skife.org/blog/2003/12/27#design-ideas ), but I am not so skilled.
Also, for Joe Developer, who probably hasn’t ever heard of AOP, this the first step to a monolithic system. I look for architecture to push the developer into consistently making good choices ( see The Pit of Success, a la Brad Abrams: http://blogs.gotdotnet.com/BradA/PermaLink.aspx/b7a0cf5c-a283-4f95-a508-819102d2feae ). Unfortunately, in an OOA Joe can make bad decisions that will have far reaching ramifications on the entire system.
I’d be very interested in hearing what Martin Fowler has to say on this issue, and hopefully we’ll see the rise of new patterns for service oriented development.
IMHO, services are a step up on the ladder from objects when it comes to architecture. Services will become the major building blocks of the future. Finally, services encourage developing coarse-grained APIs, which is exactly what will be required when the services will be distributed throughout the enterprise. Essentially, this will force us developers to deal with these important issues ahead of time. And, well, its nice to get things right the first time around. Isn’t it ?
I hope I did not give the impression that I do not respect Martin Fowler, I also hold him in very high regard. I was only trying to point out that SOA goes against alot of what he has always preached. I am going to be interested to hear what he thinks of SOA.
-James
Of course, if we include in the development process the collective code ownership advocated by Fowler, then anyone who encountered Joe’s bad code would refactor it until it was ok again ( No broken windows principle from Pragmatic Programmers ).
This is a process solution whereas SOA appears to be a structural solution to the problem I raised.
I wonder which type of solution is preferred, generally speaking: Process or Structure.
One final note =)
The example I gave of BL.Customer().GetById(id) and BL.Facade.GetCustomerById(id) was given in the context of migrating OO thinking to SO thinking. This is by no means a "Rule".
Once you give up the "everything’s an object" way of thinking, and begin to adopt services when they seem to fit, then the system’s structure becomes more suited to the tasks its required to perform. Which leads me to persistence as a service.
Although I’ll probably regret this, the great O/R debate that’s been raging recently seems to focus too much on a relatively minor portion of moderate and up complexity systems. Yes, persistence is important. No, it should not be the driving force behind your entire architecture.
And, in all this debate, nobody stops to talk about the business rules. Who says myCustomer.Save() is allowed to be called now, in this context, by the current user, etc. Where does this code fit in ?
I guess the one thing that I can say here is this: Don’t lose sight of the forest for the trees.
Comments on this entry are closed.