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.

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.

-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 ?