Fri Jan 16, 2004 3:23 am
"Robert C. Martin" <unclebob@o...> wrote in message
news:pp5f00puve9kp5ujit7ar8jqbtp2kudc00@4....
> Building models is essential to good software development. It is as
> essential as writing programs. However, there is nothing special
> about OO that make it any easier to build a model than any other
> programming technique. OO is not a modeling technique, it is a
> programming technique. The models we build to help us understand a
> domain are not OO, nor is there any benefit to making them look OO.
> Indeed, there is a definite disadvantage in trying to limit our
models
> to constructs that look like OO. Models that look like OO do not
> directly map to the implementation. There is no shortcut.
In the context of Domain-Driven Design, how do these thoughts sit
because this is the essence of a view that I am trying to reconcile
against DDD. So there are either aspects that DDD disagrees with or
aspects of DDD that I do not understand correctly (or perhaps both).
For example:
"Object-orientated programming is powerful because it is based on a
modelling paradigm, and it provides implementations of the model
constructs." [DDD Pg 51] vs "The models we build to help us
understand a domain are not OO, nor is there any benefit to making
them look OO. Indeed, there is a definite disadvantage in trying to
limit our models to constructs that look like OO"
Help
`Shane Mingins`
Yes, this sounds like a different view. I don't expect everyone to agree
with me *all* the time. :-) It isn't clear to me what he means in that
quote, so I won't jump to conclusions. I'll throw out some thoughts.
As I say in that section you quoted from, models don't have to be OO (that
much we agree on). But if you choose a non-OO model it is much harder to
have the tight connection between model and implementation that I advocate.
As he says, that limits our models. Of course, with some creativity, it
doesn't have to completely stunt our models. Chapter 9 goes into that point
somewhat. But I'm kind of surprised when he says "Models that look like OO
do not directly map to the implementation." I'd like to know what he means
by that. OO languages allow you to create 'objects' with 'attributes' and
with 'associations' to other objects.
Maybe he means that responsibilities are not directly manifested in the
program. They have to be worked out by implimenting procedural methods. In
Chapter 10 I talk about using assertions and intention-revealing interfaces
to make that kind of relationship to the model tigher, but there is no
question that these are limits of the OO paradigm. It does not give us a
fully model-driven design. That doesn't mean that it doesn't give you a leg
up, though. And you are much better off defining a model that fits well with
your paradigm (objects, in this case).
But he may be refering to what I call "expanatory models", discussed on page
41 of my book. These are models that are not intended to be the basis of the
design. These can be useful as alternative ways of explaining the domain to
people and as ways of conveying a broader scope than the program will
address, in order to give the people more context.
`Eric Evans`
Could it be that Uncle Bob might be talking about Analysis models - those OO'esq
models that
clearly never fit well onto implementation? I seem to remember reading somewhere
the certain
people believe a domain model to be an analysis model.
`Nick Robinson`
Or maybe he's talking about the large number of business applications that are currently done using the transaction script [Fowler] pattern: read some data, do some processing on it, and put the updates back, all in one quick transaction. In these systems, typical of say CICS applications, there is no rich domain model materialized in memory. This is because the applications are very short lived, often realizing just one transaction. Transaction script is a good pattern for these applications because it minimizes machine resources and is often very explicitly about what is being done - just read the script.
However, as Eric points out, these applications tend to spread domain knowledge throughout the various functions that implement the transaction scripts making systems of business applications difficult to understand, maintain, reuse, and integrate. Transaction scripts do a great job implementing the known and anticipated business functions, but new requirements or discovered opportunities can be difficult to incorporate. The functions supporting the scripts can get tangled in a complex web of calls/called dependencies, especially when the script uses services provided by other scripts. Rapidly changing business domains and middle-ware platforms make this problem even worse.
However, there are many cases where it is not possible to build applications that end up materializing a large domain model in memory just to do a couple of simple business functions. Even using patterns like unit of work and lazy load, domain models can often result in reading way too much from the database for the particular task needed. Of course finder methods can be created to return exactly what's needed, but this can degenerate to transaction script if carried too far. Same with using some meta-data driven query mechanism on the domain model. That can end up with an expensive solution to an otherwise simple problem.
Unfortunately there isn't one solution that fits all cases. But luckily we have choices. Any solution has to address scaling and change. What seems like a simple solution for a specific problem can get very complicated when that solution is integrated into a larger system of more complex problems. This is where a domain model is most helpful because it formally captures domain knowledge.
Its also possible to merge these approaches and use a domain model to implement transaction scripts.
`Jim Amsden`
"Robert C. Martin" <unclebob@o...> wrote in message
news:pp5f00puve9kp5ujit7ar8jqbtp2kudc00@4....
> Building models is essential to good software development. It is as
> essential as writing programs. However, there is nothing special
> about OO that make it any easier to build a model than any other
> programming technique. OO is not a modeling technique, it is a
> programming technique. The models we build to help us understand a
> domain are not OO, nor is there any benefit to making them look OO.
> Indeed, there is a definite disadvantage in trying to limit our models
> to constructs that look like OO. Models that look like OO do not
> directly map to the implementation. There is no shortcut.
I do not know why he said this. On the surface, it is clearly wrong.
OO is obviously a modeling technique as well as a programming technique.
The American view of OO tends to emphasize its software engineering aspects,
and Bob Martin is a proponent of this. As a modeling technique, OO has
its advantages and disadvantages. its main advantage seems to be that
people tend to find it "natural". But often it just doesn't work.
I'm on a project that simulates stars blowing up. This simulation is
not in the least object-oriented, and our best efforts to make it so
do not help at all. So, often the best model is not object-oriented.
But often it is. The fact that many models are not object-oriented does
not contradict the claim that some are.
Was this posted in this group? If so, I missed it. Perhaps he was
reacting to someone who claimed that OO was the end-all and be-all of
modeling. Or someone who claimed that modeling had to precede programming
on every project. It sounds to me like something said for effect.
`Ralph Johnson`
OOModels is mentioned on: ThreadView
