You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@isis.apache.org by da...@apache.org on 2015/04/30 18:59:44 UTC
[17/19] isis git commit: ISIS-1133: further updates to the intro doc.
ISIS-1133: further updates to the intro doc.
Project: http://git-wip-us.apache.org/repos/asf/isis/repo
Commit: http://git-wip-us.apache.org/repos/asf/isis/commit/143f190f
Tree: http://git-wip-us.apache.org/repos/asf/isis/tree/143f190f
Diff: http://git-wip-us.apache.org/repos/asf/isis/diff/143f190f
Branch: refs/heads/master
Commit: 143f190fcff3c4ca4d83aeefa8e40bb35b3310ef
Parents: 61b99ff
Author: Dan Haywood <da...@haywood-associates.co.uk>
Authored: Wed Apr 29 09:14:00 2015 +0100
Committer: Dan Haywood <da...@haywood-associates.co.uk>
Committed: Wed Apr 29 09:14:00 2015 +0100
----------------------------------------------------------------------
.../_user-guide_core-concepts_principles.adoc | 244 ++++++++++++++++++-
1 file changed, 239 insertions(+), 5 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/isis/blob/143f190f/adocs/documentation/src/main/asciidoc/user-guide/_user-guide_core-concepts_principles.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_user-guide_core-concepts_principles.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_user-guide_core-concepts_principles.adoc
index 4271abb..014a0b9 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_user-guide_core-concepts_principles.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_user-guide_core-concepts_principles.adoc
@@ -5,16 +5,250 @@
IMPORTANT: TODO
-## Domain-Driven Design
+== Domain-Driven Design
+
+There's no doubt that we developers love the challenge of understanding
+and deploying complex technologies. But understanding the nuances and
+subtleties of the business domain itself is just as great a challenge,
+perhaps more so. If we devoted our efforts to understanding and addressing
+those subtleties, we could build better, cleaner, and more maintainable
+software that did a better job for our stakeholders. And there's no doubt
+that our stakeholders would thank us for it.
+
+A couple of years back Eric Evans wrote his book Domain-Driven Design</bookname>, which is well on its way to
+becoming a seminal work. In fact, most if not all of the ideas in Evans'
+book have been expressed before, but what he did was pull those ideas
+together to show how predominantly object-oriented techniques can be used
+to develop rich, deep, insightful, and ultimately useful business
+applications.
+
+So, let's start off by reviewing the essential ideas of DDD.
+
+=== The Essentials of DDD
+
+There are two central ideas at the heart of domain-driven design.
+
+* The ubiquitous language is about getting the whole team (both domain experts and developers) to communicate more transparently
+ using a domain model.
+
+* Meanwhile, model-driven design is about capturing that model in a very straightforward manner in code.
+
+Let's look at each in turn.
+
+=== Creating a Ubiquitous Language
+
+ It's no secret that the IT industry is plagued by project failures. Too often systems take longer than intended to implement, and when finally implemented, they don't address the real requirements anyway.
+
+ Over the years we in IT have tried various approaches to address this
+ failing. Using waterfall methodologies, we've asked for requirements to
+ be fully and precisely written down before starting on anything
+ else.Waterfall methodologies Or, using
+ agile methodologies, we've realized that requirements are likely to
+ change anyway and have sought to deliver systems incrementally using
+ feedback loops to refine the implementation.Agile methodologies
+
+ But let's not get distracted talking about methodologies. At the end
+ of the day what really matters is communication between the domain
+ experts (that is, the business) who need the system and the techies
+ actually implementing it. If the two don't have and cannot evolve a
+ shared understanding of what is required, then the chance of delivering
+ a useful system will be next to nothing.Ubiquitous language
+
+ Bridging this gap is traditionally what business analysts are for;
+ they act as interpreters between the domain experts and the developers.
+ However, this still means there are two (or more) languages in use,
+ making it difficult to verify that the system being built is correct. If
+ the analyst mistranslates a requirement, then neither the domain expert
+ nor the application developer will discover this until (at best) the
+ application is first demonstrated or (much worse) an end user sounds
+ the alarm once the application has been deployed into production.
+
+ Rather than trying to translate between a business language and a
+ technical language, with _D_ we aim to have the
+ business and developers using the same terms for the same concepts in order to
+ create a single <firstuse>domain model</firstuse>.Domain-driven design (DDD)</i> This domain model
+ identifies the relevant concepts of the domain, how they relate, and
+ ultimately where the responsibilities are. This single domain model
+ provides the vocabulary for the *e* for our
+ system.<footnote>
+ <p>In Extreme Programming, there is a similar idea called
+ a *s*. But *e* is much more
+ evocative.</p>
+ </footnote></p>
+
+ <ddd>
+ <title>Ubiquitous Language</title>
+
+ <p>Build a common language between the domain experts and developers
+ by using the concepts of the domain model as the primary means of
+ communication. Use the terms in speech, in diagrams, in writing, and when
+ presenting.</p>
+
+ <p>If an idea cannot be expressed using this set of concepts, then go
+ back and extend the model. Look for and remove ambiguities and
+ inconsistencies.</p>
+ </ddd>
+
+ <p>Creating a *e* calls upon everyone involved in the system's development
+ to express what they are doing through the vocabulary provided by the
+ model. If this can't be done, then our model is incomplete. Finding the
+ missing words deepens our understanding of the domain being modeled.</p>
+
+ <p>This might sound like nothing more than me insisting that the
+ developers shouldn't use jargon when talking to the business. Well,
+ that's true enough, but it's not a one-way street. A *e* demands that the developers work hard to understand the
+ problem domain, but it also demands that the business works hard in
+ being *e* in its naming and descriptions of those
+ concepts. After all, ultimately the developers will have to express
+ those concepts in a computer programming language.</p>
+
+ Also, although here I'm talking about the "domain experts" as being a
+ homogeneous group of people, often they may come from different branches
+ of the business. Even if we weren't building a computer system, there's a
+ lot of value in helping the domain experts standardize their own
+ terminology.<i>Domain experts</i> Is the marketing department's "prospect" the same as sales'
+ "customer," and is that the same as an after-sales<layout>\break{}</layout> "contract"?</p>
+
+ <p>The need for precision within the *e*
+ also helps us scope the system.<i>Domain-driven design (DDD)</i><i>Scoping the system</i> Most business processes evolve piecemeal
+ and are often quite ill-defined. If the domain experts have a very good
+ idea of what the business process should be, then that's a good
+ candidate for automation, that is, including it in the scope of the
+ system. But if the domain experts find it hard to agree, then it's
+ probably best to leave it out. After all, human beings are rather more
+ capable of dealing with fuzzy situations than computers.</p>
+
+ <p>So, if the development team (business and developers together)
+ continually searches to build their *e*,
+ then the domain model naturally becomes richer as the nuances of the
+ domain are uncovered. At the same time, the knowledge of the business
+ domain experts also deepens as edge conditions and contradictions that
+ have previously been overlooked are explored.</p>
+
+ <p>We use the *e* to build up a domain
+ model. But what do we do *h* that model? The answer to
+ that is the second of our central ideas.<i startref="idx.gettingstarted1">Domain-driven design (DDD)</i><i startref="idx.gettingstarted2">Ubiquitous language</i></p>
+
+ <sect2>
+ <title>Model-Driven Design</title>
+
+ <p>Of the various methodologies that the IT industry has tried, many
+ advocate the production of separate analysis models and implementation
+ models. <i class="StartOfRange" id="idx.gettingstarted3">Model-driven design</i> A recent example is that of the _G_'s Model-Driven Architecture (_A_) initiative, with its
+ platform-independent model (the _M_) and a
+ platform-specific model (the _M_).<i>Model-driven design</i></p>
+
+ <p>Bah and humbug! If we use our *e* just
+ to build up a high-level analysis model, then we will re-create the
+ communication divide. The domain experts and business analysts will look
+ only to the analysis model, and the developers will look only to the
+ implementation model. Unless the mapping between the two is completely
+ mechanical, inevitably the two will diverge.<i>Analysis model</i><i>Implementation model</i></p>
+
+ <p>What do we mean by *l* anyway?<i>Domain-driven design (DDD)</i> For some, the term will bring to
+ mind _L_ class or sequence diagrams and the like. But
+ this isn't a model; it's a visual *n* of some
+ aspect of a model. No, a domain model is a group of related concepts,
+ identifying them, naming them, and defining how they relate. What is in
+ the model depends on what our objective is. We're not looking to simply
+ model everything that's out there in the real world. Instead, we want to
+ take a relevant abstraction or simplification of it and then make it do
+ something useful for us. Oft quoted and still true is that a model is neither
+ right nor wrong, just more or less useful.</p>
+
+ <p>For our *e* to have value, the domain
+ model that encodes it must have a straightforward, literal
+ representation to the design of the software, specifically to the implementation. Our
+ software's design should be driven by this model; we should have a
+ *n*.</p>
+
+ <ddd>
+ <title>Model-Driven Design</title>
+
+ <p>There must be a straightforward and very literal way to represent
+ the domain model in terms of software. The model should balance these
+ two requirements: form the *e* of the
+ development team and be representable in code.<i>Domain model</i></p>
+
+ <p>Changing the code means changing the model; refining the model
+ requires a change to the code.</p>
+ </ddd>
+
+ <p>Here also the word *n* might mislead; some might again be
+ thinking of design documents and design diagrams.<i>Model-driven design</i><i>Design</i> But by *n* we mean
+ a way of organizing the domain concepts, which in turn leads to the way
+ in which we organize their representation in code.</p>
+
+ <p>Luckily, using <firstuse>object-oriented</firstuse>
+ (_O_) languages such as Java, this is relatively easy
+ to do; _O_ is based on a modeling paradigm anyway.<i>Model-driven design</i> We
+ can express domain concepts using classes and interfaces, and we can
+ express the relationships between those concepts using associations.<i>Object-oriented (OO) languages</i></p>
+ </sect2>
+
+ <p>So far so good. Or maybe, so far so much motherhood and apple pie.
+ Understanding the _D_ concepts isn't the same as being
+ able to apply them, and some of the _D_ ideas can be
+ difficult to put into practice. What this book is about is how Naked
+ Objects eases that path by applying these central ideas of
+ _D_ in a very concrete way. So, now would be a good time
+ to see how.<i startref="idx.gettingstarted3">Model-driven design</i></p>
-### Ubiquitous Language
-IMPORTANT: TODO
+## Naked Objects Pattern
-yada yada yada
+Apache Isis implements the naked objects pattern, originally formulated by Richard Pawson. So who better than Richard to explain the origination of the idea?
+[TIP]
+====
+The Naked Objects pattern arose, at least in part, from my own
+frustration at the lack of success of the domain-driven approach. Good examples
+were hard to find--as they are still.
+
+A common complaint from _DDD_ practitioners was that it
+was hard to gain enough commitment from business stakeholders, or even to
+engage them at all. My own experience suggested that it was nearly
+impossible to engage business managers with _UML_ diagrams.
+It was much easier to engage them in rapid prototyping--where they could
+see and interact with the results--but most forms of rapid prototyping
+concentrate on the presentation layer, often at the expense of the
+underlying model and certainly at the expense of abstract thinking.
+
+Even if you could engage the business sponsors sufficiently to design a
+domain model, by the time you'd finished developing the system on top of the
+domain model, most of its benefits had disappeared. It's all very well
+creating an agile domain object model, but if any change to that model
+also dictates the modification of one or more layers underneath it (dealing
+with persistence) and multiple layers on top (dealing with presentation),
+then that agility is practically worthless.
+
+The other concern that gave rise to the birth of Naked Objects was how to
+make user interfaces of mainstream business systems more "expressive"--how
+to make them feel more like using a drawing program or
+_CAD_ system. Most business systems are not at all
+expressive; they treat the user merely as a dumb
+*process-follower*, rather than as an empowered
+*problem-solver*. Even the so-called usability experts had little
+to say on the subject: try finding the word "empowerment" or any synonym
+thereof in the index of any book on usability. Research had demonstrated
+that the best way to achieve expressiveness was to create an object-oriented
+user interface (_OOUI_). In practice, though, __OOUI__s were notoriously hard to develop.
+
+Sometime in the late 1990s, it dawned on me that if the domain model
+really did represent the "ubiquitous language" of the
+business and those domain objects were behaviorally rich (that is,
+business logic is encapsulated as methods on the domain objects rather than
+in procedural scripts on top of them), then the _UI_ could
+be nothing more than a reflection of the user interface. This would solve
+both of my concerns. It would make it easier to do domain-driven design,
+because one could instantly translate evolving domain modeling ideas
+into a working prototype. And it would deliver an expressive,
+object-oriented user interface for free. Thus was born the idea of Naked
+Objects.
+
+-- Richard Pawson, from the foreword to Dan Haywood's "Domain Driven Design using Naked Objects"
+====
-## Naked Objects Pattern
[TIP]
.Object Interface Mapping