Domain Driven Design conflicts with Coopers Interaction Design...

25 Jun 2007 - 8:15pm
7 years ago
3 replies
1260 reads
Michael Scharf
2007

Hi,

I am reading "About Faces 3" and I like most of the ideas
that Cooper et al present a lot.

However, I very much disagree with the "Represented Model"
versus "Implementation Model" discussions in Chapter 2.

The reason is, if the represented model is not the
implementation model, then (in most cases) the mismatch
between the implementation model and represented model will
"shine through".

"Domain Driven Design" uses different approach, described
Eric Evans book "Domain Driven Design":
http://www.awprofessional.com/bookstore/product.asp?isbn=0321125215&redir=1&rl=1
And the first chapter of the book :
http://domaindrivendesign.org/books/chapter01.pdf

From the http://DomainDrivenDesign.org/ web-page:

"The premise of domain-driven design is two-fold:
* For most software projects, the primary focus
should be on the domain and domain logic; and
* Complex domain designs should be based on a model.
Domain-driven design is not a technology or a methodology.
It is a way of thinking and a set of priorities, aimed at
accelerating software projects that have to deal with
complicated domains."

One of the central ideas of DDD (Domain Driven Design) is
the use of a "ubiquitous language". This language is not
only used to in the analysis, the UI or the documentation,
it is also used in the implementation.

It is the language of the "mental model" of the users.
Language is a very important way to structure our world in a
consistent way. With the language we can describe the model,
we can reason and it can be communicated to user. Therefore
it is important to use the language the users use to
describe their domain.

This seems all very similar and consistent with the concepts
of interaction design, but unless the represented model IS
the implementation model, it will always be very hard for
developers to get it right.

For me it seems the interaction design "ideal" of hiding the
"Implementation Model" from "Represented Model" is
contradicting with Domain Driven Design, because idea of
hiding the domain model from the user is the "enemy" of
DDD...

My personal conclusion is to combine the two approaches: use
interaction designs and goal directed design to model
Personas and the mental model of the Personas of the domain,
but use domain driven design to come up with a ubiquitous
language to represents the domain and the interaction model.
In one sentence: "implement the mental model"

What makes me struggle is the different Personas:
is it possible to come up with one model for all Personas
or would there be different models for different Personas?

What do you think?
Am I missing something?
Do you know or use Domain Driven Design?
How would you combine IxD and DDD?
Or is there a real contradiction?

Michael

Comments

25 Jun 2007 - 9:26pm
Bruce Esrig
2006

I'll venture an answer that supports your observations. The short version
is: yes, there is a conflict, but it comes from constraints on what you are
permitted to do in the implementation, not from a deficiency in Cooper's
approach to interaction design. The distinction that you describe from
Cooper seems to acknowledge a constraint that is not acknowledged by Domain
Driven Design.

For those with database experience, the answer I'm offering is based in
part on observations from a project that attempted to represent an
object-oriented model in the user interface, but to implement it in a
relational database. The object-oriented model permitted arbitrary nesting.
The relational model (in the default implementation) asked that the maximum
nesting depth be anticipated and specified so that data could be recorded
in different columns depending on the nesting level that the data supports.

If you are designing from scratch and the system architecture can be freely
determined without regard to cost, then there is a decent chance that the
Domain Driven Design program will succeed. The implementation model can be
constructed as a natural refinement of the represented model.

If there are prior constraints on the system architecture that partially
determine the implementation model (in the example: "use a relational
database on the back end"), then a new represented model can only be pasted
on top. In this situation, if user-centered design is used at the user
interface level, it is likely that some building will have to be done to
construct an interface that matches the user's mental model ... that is, it
requires special effort (implementation excise?) to build the interface
from the ingredients provided by the implementation model.

In a user-centered design, the interaction design at the user interface
level is done with user goals and scenarios in mind. These user goals and
scenarios are based on the personas. For any given persona, there is a
language in which the user goals and scenarios are stated. This language
informs you of the meaningful objects and relationships that the user
perceives.

In a data-driven approach (like DDD without the capital letters), the
problem that needs to be solved is the problem of finding suitable
generalizations of the dialects used by different personas. In the mode
where you are reconciling, you seek common general names for the ideas that
match, even when the various personas call the same idea different things.
As reconciliation occurs, it becomes possible to establish a single
language in which the entire design makes sense and can be explained and
can operate. This is sometimes followed by personalization, in which the
different personas may subsequently be allowed to use their separate
languages for otherwise closely related ideas. Once the languages are
separated again, different features may be elevated for each persona, to
correspond to the emphasis perceived by each persona.

Notice that a single language is only possible if there is actually a
common substrate of principles that are the same across the community. This
is often not the case in political discussions. As a result, different
personas may use different languages, and there may be no single model that
implements the ideas behind the represented model. Instead, the
implementation may have areas of overlap, but the underlying model may
contain regions that support one persona but are incompatible with another.
So you can have factual content for one persona that can't be shown to
another persona because the two personas disagree on which concepts are valid.

Returning to a safer, technical sphere, if there is a single unifying
reality behind the design, then it should be possible to represent it.
Whether the representation model can be implemented directly depends,
mainly, on whether there are legacy systems involved whose boundaries are
being crossed by the representation model, and on whether new systems have
been committed to that also don't align with the representation model.

Best wishes,

Bruce Esrig

At 09:15 PM 6/25/2007, Michael Scharf wrote:
>Hi,
>
>I am reading "About Faces 3" and I like most of the ideas
>that Cooper et al present a lot.
>
>However, I very much disagree with the "Represented Model"
>versus "Implementation Model" discussions in Chapter 2.
>
>The reason is, if the represented model is not the
>implementation model, then (in most cases) the mismatch
>between the implementation model and represented model will
>"shine through".
>
>"Domain Driven Design" uses different approach, described
>Eric Evans book "Domain Driven Design":
>
>http://www.awprofessional.com/bookstore/product.asp?isbn=0321125215&redir=1&rl=1
>And the first chapter of the book :
> http://domaindrivendesign.org/books/chapter01.pdf
>
> From the http://DomainDrivenDesign.org/ web-page:
>
>"The premise of domain-driven design is two-fold:
> * For most software projects, the primary focus
> should be on the domain and domain logic; and
> * Complex domain designs should be based on a model.
> Domain-driven design is not a technology or a methodology.
> It is a way of thinking and a set of priorities, aimed at
> accelerating software projects that have to deal with
> complicated domains."
>
>One of the central ideas of DDD (Domain Driven Design) is
>the use of a "ubiquitous language". This language is not
>only used to in the analysis, the UI or the documentation,
>it is also used in the implementation.
>
>It is the language of the "mental model" of the users.
>Language is a very important way to structure our world in a
>consistent way. With the language we can describe the model,
>we can reason and it can be communicated to user. Therefore
>it is important to use the language the users use to
>describe their domain.
>
>This seems all very similar and consistent with the concepts
>of interaction design, but unless the represented model IS
>the implementation model, it will always be very hard for
>developers to get it right.
>
>For me it seems the interaction design "ideal" of hiding the
>"Implementation Model" from "Represented Model" is
>contradicting with Domain Driven Design, because idea of
>hiding the domain model from the user is the "enemy" of
>DDD...
>
>My personal conclusion is to combine the two approaches: use
>interaction designs and goal directed design to model
>Personas and the mental model of the Personas of the domain,
>but use domain driven design to come up with a ubiquitous
>language to represents the domain and the interaction model.
>In one sentence: "implement the mental model"
>
>What makes me struggle is the different Personas:
>is it possible to come up with one model for all Personas
>or would there be different models for different Personas?
>
>What do you think?
>Am I missing something?
>Do you know or use Domain Driven Design?
>How would you combine IxD and DDD?
>Or is there a real contradiction?
>
>
>Michael
>
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://beta.ixda.org/guidelines
>List Help .................. http://beta.ixda.org/help
>Unsubscribe ................ http://beta.ixda.org/unsubscribe
>Questions .................. list at ixda.org
>Home ....................... http://beta.ixda.org

26 Jun 2007 - 9:29am
Michael Micheletti
2006

Michael,

Thanks for the book recommendation. I hadn't heard of it before and it's
moved onto my reading list. Your one sentence summation resonates. All the
best,

Michael Micheletti

On 6/25/07, Michael Scharf <ixda at scharf.gr> wrote:
>
> In one sentence: "implement the mental model"
>

26 Jun 2007 - 11:37pm
Michael Scharf
2007

Bruce,

thank you for your long answer!

> For those with database experience, the answer I'm offering is based in
> part on observations from a project that attempted to represent an
> object-oriented model in the user interface, but to implement it in a
> relational database.

There are ways of mapping object oriented models to relational databases.
If the user interface is represented as an object oriented model and if
this model is not really represented in code but only "faked", then
there is a high probability of having inconsistencies. If the
objects, the relations and the artifacts are formalized into a
software model, it is much easier to reason about it and to
prove the "mental model". If a ubiquitous language is used to
describe the mental model(s), it will be much simpler to
communicate between the different stakeholders. How else
would you communicate with the developers? How to test the
model? How to explain the model to the different users, if
it cannot be described in a formal way?

> The object-oriented model permitted arbitrary
> nesting. The relational model (in the default implementation) asked that
> the maximum nesting depth be anticipated and specified so that data
> could be recorded in different columns depending on the nesting level
> that the data supports.

...and how do you present arbitrary nesting to the user? You have to create
a model that permits is. Or you explain the user that there's a limit to
nesting. In either case the implementation model is what the user interacts
with.

> If you are designing from scratch and the system architecture can be
> freely determined without regard to cost, then there is a decent chance
> that the Domain Driven Design program will succeed. The implementation
> model can be constructed as a natural refinement of the represented model.

...and if you create a user interface on top of an existing application,
you need to create the interaction model in some way! Here DDD can
help to come up with a consistent model.

> If there are prior constraints on the system architecture that partially
> determine the implementation model (in the example: "use a relational
> database on the back end"), then a new represented model can only be
> pasted on top. In this situation, if user-centered design is used at the
> user interface level, it is likely that some building will have to be
> done to construct an interface that matches the user's mental model ...

:-) and that's where DD helps to communicate with the developers....

> that is, it requires special effort (implementation excise?) to build
> the interface from the ingredients provided by the implementation model.

Developers tend to get lost in details. They know all the technical
problem and edge cases. If you ask them to create a formal mental
model, they would know how they can build it on top of the implementation
model. In many cases they would refactor and adapt the implementation.
DDD does not prevent you from having multiple layers or different
sub-domains. But if the mental model only exists on paper or in
the head of the interaction designers, it well be very hard to
implement. Developers should take part in the definition of the
mental model. They are usually very good at formalizing such
a model. They can find inconsistencies. Just use the power of
natural language and the translation into formal programming
languages.

It is also important to use the same language in the UI and in the
implementation. Developers have to learn and use the language of
the domain and the mental model. Else they have a private translation
table. But using a different language in the implementation leads
to different reasoning and conclusions about the model....

I have seen too many times that developers use a totally different
language to describe the system than it is presented to the user.
That causes all kinds of problems and often the implementation
concepts shine through....

> This
> language informs you of the meaningful objects and relationships that
> the user perceives.

... and it has to be implemented is *some* way!

> In a data-driven approach (like DDD without the capital letters), the
> problem that needs to be solved is the problem of finding suitable
> generalizations of the dialects used by different personas. In the mode
> where you are reconciling, you seek common general names for the ideas
> that match, even when the various personas call the same idea different
> things. As reconciliation occurs, it becomes possible to establish a
> single language in which the entire design makes sense and can be
> explained and can operate. This is sometimes followed by
> personalization, in which the different personas may subsequently be
> allowed to use their separate languages for otherwise closely related
> ideas. Once the languages are separated again, different features may be
> elevated for each persona, to correspond to the emphasis perceived by
> each persona.

This sounds great, but this will become *very* complicated unless
you have a formal translation table between the different languages
mental models. I think formalizing the models, the language and
the relationship between the artifacts would help a lot.

> Notice that a single language is only possible if there is actually a
> common substrate of principles that are the same across the community.

Can you give me an example where different personas act on the
same artifacts, but use a different language?

> This is often not the case in political discussions. As a result,
> different personas may use different languages, and there may be no
> single model that implements the ideas behind the represented model.

...and to make them understand each other, they need to come up with
some common definitions and some common model they can agree on.
They might need some translation between different terms too....

> Instead, the implementation may have areas of overlap, but the
> underlying model may contain regions that support one persona but are
> incompatible with another. So you can have factual content for one
> persona that can't be shown to another persona because the two personas
> disagree on which concepts are valid.

But unless you model the mental models of the different personas,
it will be very hard implement such a system....

> Returning to a safer, technical sphere, if there is a single unifying
> reality behind the design, then it should be possible to represent it.

In the end, we write software. The software implements the artifact the
user interacts with. There *always* is a single unifying reality behind
the design: the implementation.

> Whether the representation model can be implemented directly depends,
> mainly, on whether there are legacy systems involved whose boundaries
> are being crossed by the representation model, and on whether new
> systems have been committed to that also don't align with the
> representation model.

I think we *always* implement the representation model. But if we don't
use the same techniques we use for our software frameworks and architecture
it will be a shallow surface on the "real model". Why not making the
representation the "real model"?

Michael
--
http://MichaelScharf.blogspot.com/

Syndicate content Get the feed