|
|
|
Re: Taking sides with clemens
|
Thursday, March 23, 2006
|
In the last couple of weeks, Clemens Vasters and Sten Sundbland
(amongst others) have been trying to fire some shells towards the O/R
and object-oriented community. Both of them advocating message based
architecture over any OO-model.
Clemens on one hand has some great points but most of them are rooted
in lack of O/R experience (according to his last post he tried O/R out
in 1999 with a hand crafted mapper). Sten on his side tries to throw a
huge rock onto Domain-Driven Design.
Now a couple of points these gentlemen are missing;
1) As little as DDD or O/R is a silver bullet, as little is SOA it
either. SO is a great architecture for building systems that should
interact with each other, but not to effectively build applications.
Now with Web 2.0 around the corner, service interfaces grows more in
importance but most systems today are not best modeled based on
messages.
To begin with, organizations today think of messages to a very little
extent. Businesses today are still trying to figure out their internal
processes and are not about to start explaining them in messages any
time soon. Speaking with clients I'm glad if I get them to understand
simple business/application mapping. It might be that I'm no good at
it, but almost all of my colleagues tell the same story.
Some international enterprise sized clients do actually understand
messages, but most of them use them in terms of integration, not
architecture.
2) The database is storage, not a system driver. How the data is stored
is really important, but the storage should not drive the application /
system development. Well, for legacy systems it more often than not
puts a mark in the constraints column, but then again that is true for
all paradigms. Sometimes when I talk to architects that have been
around since the white coats, I see reluctance to let the grip of how
the data gets stored and retrieved from the storage. This is the same
kind of reluctance that C++ programmers still have about the Garbage
Collector. I can understand this to some extent, if you're really good
at hand crafting SQL you might do a better job than any generic DAL,
but then again you might not.
What I don't understand is how messages utterly defining the data storage structure differ from classes defining it.
I'm also a bit curious why no object oriented paradigm ever hit VB1-6
trained developers; they've jumped from data structures representing
the tables in a database to SOA without passing OO at all. Why is that?
Could it be that VB developers never got the chance to implement OO
systems to full extent?
3) DDD is not only an object oriented technique. DDD is built on many
practices which captures the business in some kind of model. "The domain". However this doesn't imply "implementation right away
kind" of applications. It is possible, although not recommended, to get
a functional model without ever writing code. The problem with doing so
is that usually when we start to implement code and let it interact, we
find flaws in our initial design.
Another strong driving factor is that doing design iterations together
with the client will considerably help the architect and the developers
to get to know the domain. As well as get the domain expert to get to
know how the business process could be captured in their system. These
iterations are aimed towards avoiding a scenario where the design just
doesn't get it.
Now when it comes to messages, if parts of the system require sending
messages, those messages (or message classes) could be defined with
subsets of DDD in cooperation with the client for later implementation
as a service bus.
Another question where the answer has eloped me is business rules. If
the only abstraction against your data is XML documents and messages,
where do you put your business rules? In the client or in the database?
None of those strategies have been successful in the past years.
One could argue that some of the business rules might fit into some
kind of workflow engine. In a couple of cases this really makes sense,
but, we don't have a really good workflow engine as of today. So
advocating that would really be looking at the future, not the present.
I could rant for hours about these things.
A short summary though, as much as the SOA community claims that people
uses O/R or DDD don't understand SOA, they themselves usually don't
understand O/R or DDD. I also think it's very dangerous when architects
disconnects themselves from the low level details of the implementation
of a system and just sits in their space crafts looking down.
Also; a good architect has more than one tool in their toolbox; they
learn and understand why and when different paradigms work best.
Because you have to remember; in numerous tales, even werewolves got
immune to silver bullets.
--
Links:
The sirens are singing: O/R mapping
Taking sides with Clemens
|
|
|
|
|
|
|
Comments
|
|
3/24/2006 9:30:00 AM
http://martin.rosenlidholm.googlepages.com/
-
Martin Rosén-Lidholm
|
|
|
Well put!
// Martin - taking sides with Patrik!
|
|
|
|
|
5/18/2006 10:35:00 PM
http://www.base4.net/Blog.aspx
-
Alex James
|
|
|
|
Nice summary! I like the werewolf bit!
|
|
|
|
|
2/17/2007 1:24:00 AM
http://certifiedarchitect.blogspot.com/
-
Anders Tornblad
|
|
|
You have lots of good points, but I feel I just have to respond to this bit:
"What I don't understand is how messages utterly defining the data storage structure differ from classes defining it."
The messages DO NOT (and should not) define data storage structures. Messages only define data storage structures when you do chatty interfaces (which has bad performance) or CRUD (which most of the time is too costly).
The message you send to a service makes no assumptions at all about the internal implementation of that service. It is simply a way of saying "this is the action that I wish to perform, and all the information needed to complete the action". The information could be (and probably is) regarding several different domain objects.
Use DDD and O/R all you want when implementing a service - that is not what SOA is about. Just as you said yourself: "SO is a great architecture for building systems that should interact with each other, but not to effectively build applications."
|
|
|
|
|
2/17/2007 11:08:00 AM
http://www.lowendahl.net
-
Patrik Löwendahl
|
|
|
|
Yes, that is my point and this post is a comment to "The sirens are signing: O/R mapping" and "Taking side with clemens". Two posts that clearly argue that building with SO creates restraints on the datamodel which then disqualifies DDD and O/R mapping, that is the starting point for my arguments here. Your points are very valid and totally inline in what I'm trying to communicate.
|
|
Comment
|
|