This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: A collection of comments
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
After spending quite some time commenting on other people's posts about SOA, I thought I'd bring them all together in a post. My apologies for not editing it into a single coherent post.
Following "Adventures in SOA, Part 2": from my comments:
If you want to go SOA all the way, Fowler's domain model doesn't quite fit. This is because it exists in the context of an OO architecture.
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.
Following "Adventures in SOA, Part 3": from my first comment:
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.
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.
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 ?
from my second comment:
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.
Following "Adventures in SOA, Part 4": my comment:
int Id { get; set; }
string Name { get; set; }
string Address { get; set; }
etc...
Note that you would implement basic validation checks in the setters - such as checking the string passed in is of the appropriate length.
Now the Entities "layer" is really just a part of the common type system for the application. So, when distributing your services and setting up the calls over web services or message queuing, these entities will be passed as Xml.
This is how you move to the "Share schema, not type" directive, since, all these entities in essence just define a schema. From an implementation perspective, yes, they are a type too, but that's really just internal to the service.
And a final note:
The set of Service Layer, Remote Facade, and Data Transfer Object patterns ( from Fowler's PoEEA ) are essential components of SOA. The Data Transfer Object pattern is implemented by what I call entities. These entities form the schema in SOA.
Previous Topic
