I thought I'd jot down my impressions of ideas and trends that I noticed at
OOPSLA and that seem relevant to domain-driven design. This is by no means a
balanced assessment of the conference. This is OOPSLA through my eyes.
Most striking was the amount of activity around domain modeling and design
this year, much more than in earlier years. Partly this may have been
emphasized by the track, but I think more people are becoming aware that our
biggest challenges lie in that area.
Within this general interest in domain design, two particular techniques got
a lot of attention, "model-driven architecture" and "domain-specific
languages".
Model-driven architecture (MDA)
---------------------------
I'll tell you right up front; I'm not a believer in this approach. Most of
what comes under this name consists of describing part of the system in UML
and then generating program code. Attempts to shield us from code amount to
forcing us to program in a much more restrictive programming language (e.g.
UML). While this can be useful for some subset of applications, I think it
is a dead end.
As most of you know by now, I believe in building up the domain language
based on a model and bringing that language and model to life in code. A
programming language that made model expression easier would be most
welcome, but UML is not that language.
There was a lot of discussion about this at OOPSLA by many enthusiasts and
many skeptics. One of the high-points of the conference was a surprising
panel discussion on this topic, surprising because it cut to the deep issues
and because the participants did not mince words. I greatly enjoyed the
comments of Dave Thomas (the lead skeptical panelist) partly because I
agreed with him. But one pro-MDA panelist, Stephen Mellor, seemed to have a
pretty sensible approach. He said "I live in a state machine, and I'm quite
happy living in a state machine", thereby narrowing his focus to an
important subset of applications. He also was not wedded to UML, but just
wanted some language that let him specify his models. His group has actually
worked out semantics for doing this using subsets of UML to provide action
semantics, etc. People with his perspective might turn this into a useful
specialty technique.
Domain-specific languages (DSL)
---------------------------
I like this concept (and discussed it in my book, page 272), but I have
reservations. The problem in practice, usually, is that the DSL is
disconnected from the programming language it is built on. The distinction
between using the language and developing the language is not sharp, as they
coevolve and insight deepens. (Well, it is forced to be a sharp distinction
in such an environment.) It is hard to continue refining the domain-specific
language once programs have been written in it. Debugging is hard. IDEs,
test frameworks and refactoring tools don't exist.
Developing a set of well abstracted objects or other constructs in the
general programming language can also provide developers with an expressive,
specialized language. True, the syntax will not be tailored, but the
syntaxes of general languages are not that bad if you work at making the
design supple. Smalltalk is better for this than Java because there is so
much less incidental clutter. The functional languages, such as the LISP
family, allow programmers to devise seamless DSLs. Some new language might
make this situation much better.
The distinct DSL does have its areas of applicability, especially when the
DSL can be peculiarly stable, when it is a scripting language for control by
end users or an embedded processor.
Specific solutions for narrow problems
----------------------------------
I was quite interested in a few people who were not trying to create a grand
new technology, but were working on model-driven solution to a specific
problem that comes up all the time in OO Programming: tracking change
through time. "Time Conscious Objects" are ordinary Java objects
(potentially preexisting) with some extra behavior attached by their code
generator. These TCOs automatically keep a history of their attributes. They
can compare attributes at different points in time, and all sorts of other
neat tricks. They get a lot of powerful behavior out of a quite simple
addition to the code because they have found a deep model within this narrow
generic domain. The paper is interesting
(
http://portal.acm.org/citation.cfm?id=949344.949376&dl=portal&dl=ACM&type=s
eries&idx=949344&part=Proceedings&WantType=Proceedings&title=Conference%20on
%20Object%20Oriented%20Programming%20Systems%20Languages%20and%20Application
s). This is in early development, but I hope it will eventually be useful to
many projects.
Imagine if we had such powerful yet simple solutions to even five basic OO
modeling challenges. There is more than one way to raise the level of
abstraction of programming. This really has me thinking.
EricEvansOOPSLAObservations is mentioned on: ThreadView
