Hi,

I wanted to comment on this section but was unable to access
your website the other day.  It may be due to where I am working.
Can you confirm for me that your webpage

http://domainlanguage.com/book.html

is up an running?

Cheers

Jonathan

--- In domaindrivendesign@yahoogroups.com, "Eric Evans <eric@d...>"
<eric@d...> wrote:
> I'm hoping the people here can help me brainstorm a name for this
> pattern, and I can get a feel for how different people react.
>
> This was previously called "concept contouring granularity". That
> was a mouthful. In the new, January 26th draft, it is
> called "conceptual contours".  I've tried lots of names. Among them,
>
> shearing points
> conceptual shearing points
> natural shearing points
> conceptual granularity
> natural grain
>
> and, at the moment,
> conceptual contours
>
> Ideas? Preferences?
>
> Thanks,
> Eric

I can't see the page either.  I wonder which domain layer of the site is
having problems?  ;-)

--jk

The website is down today. I'm told it will be back up tonight. In
the meantime, I put the pdf of the book in the "Files" section of
this group. Sorry for the inconvenience, and thanks for making me
aware of the problem.

-Eric

I like the name conceptual contours more then
concept contouring granularity.

Others I thought might apply:

Conceptual form
Conceptual shape
Conceptual implementation

My vote is still for the one you have in the current draft.


--- In domaindrivendesign@yahoogroups.com, "Eric Evans <eric@d...>"
<eric@d...> wrote:
> I'm hoping the people here can help me brainstorm a name for this
> pattern, and I can get a feel for how different people react.
>
> This was previously called "concept contouring granularity". That
> was a mouthful. In the new, January 26th draft, it is
> called "conceptual contours".  I've tried lots of names. Among them,
>
> shearing points
> conceptual shearing points
> natural shearing points
> conceptual granularity
> natural grain
>
> and, at the moment,
> conceptual contours
>
> Ideas? Preferences?
>
> Thanks,
> Eric

Domain driven design addresses the modeling/structuring of
the "business object tier" of a system ... developing a
deeper understand about the domain and modeling the
software around the "guts" of the domain ... I can see how
this results in a flexible design - the model mirrors what's
happening in the real world and if things change it maps
nicely into the model making the change "natural", easier,
i.e. the design is flexible.

I am interested in some thoughts / comments on is how this
relates to functional application design: One approach to
get this right is the use case driven approach - trying to
work out what users actually want to accomplish with the
system and using this as the driving force for the modeling.
Use cases often often cross multiple "business objects", so if
you use them to drive the design, you end up with different
underlying model than using the DDD approach - the result
is software which is tailored to user needs but is less
flexible.

It seems you need to need both approaches - use cases for the
application flow (and presentation layer follows from there)
and domain analysis for the business logic layer (and data
layer follows from there). Question is, which model should be
the driving  force? Also, if you need both models, how do you
synch them up?

I guess one idea is to use the use case model to verify the
domain model?

Am very interested in comments, insights ...
Cheers,

Robert.

I think this question implies that you are looking for a
mechanistic solution.  Why should either use cases or
the domain model dominate?  That is like asking whether
your life should be dominated by the need for food or
by the need for shelter.  A use case driven approach is
best at the beginning of a project, when you don't know
the domain that well.  Use cases are always helpful for
explaining the system to others.  But the real goal of
the process described in the book is to develop a language;
first a human language shared by developers and their customers
and then a language used to describe the system to the computer.
Use cases are a tool for helping us understand a system, but
the real goal is the understanding, not the use cases.

This book is not about developing a system in six months.
It is about developing a system over the course of several
years, continuously adding features as the customers request
them.  It is as much about how to maintain a system as it
is how to develop it in the first place.

-Ralph Johnson

Hi Eric,

A colleague just informed me of your DDD work. He mentioned to me
that you were also trying to set up a collaboration portal (see
http://www.domaindrivendesign.org/discussion/index.html). Perhaps you
and your group would like to consider using CollaborativeAID. It is
free for non-profit organizations and egroup communities. It is
essentially an enterprise Wiki with:
- namespace support
- authentication delegated to a nominated security realm
- in built support for authorization using ~.access (ACLs) artifacts
to help moderate/control the Wiki folder's
- the ability to not just cite, but include other artifacts  (ie.
diagrams) – leads to less duplication
- a meta-model free agile modeling editor implemented in Java
WebStart that supports the maintenance of:
   - UML diagrams
   - screen sketches
   - context diagrams
- google style search engine which enables you to search for content
that spans textual/diagram artifacts using (+, -, AND, OR, proximity,
fuzzy, grouping etc.) and semantic searching capability
- OCP (Open for extension but closed for modification) support:
   - Define your own artifact types (the reference Compiler
implementation source-code is provided for *.properties, *.java,
*.htm? *.xml *.svg file)
   - Define your own connectors to connect to any EIS system
(Connector for CVS is provided for Software Configuration Management)
- ...

Yes, as you gathered I can go on and on. I wrote the thing 2 years
ago because I became so passionate about:
- Ward Cunningham's Wiki metaphor/design principles
- Ellen Gottesdiener's – Wall of Wonder approach to collaboration
- Scott Ambler's – Agile Modeling conceptual framework

My vision was:
1. an environment that actively engages *all* stakeholders by
supporting:
   - parallel contributions
   - syntax free contributions
   - simple/primitive tooling
2. all artifacts (ie. models, source-code, test-case's, sketches,
etc.) should be first class elements of the collaborative development
environment
3. all artifacts should be able to support polymorphic artifact
behavior
----

Anyway, I wish you all the best of luck with the book. Well done for
maintaining and realizing a vision for over 4 years. I have the
greatest respect for anybody that creates a published book (I've
tried myself and discovered that it is the hardest system to write).

rgds ash
http://www.self.com.au <self mission="Helping you get there on your
own"/>

Note:
i) CollaborativeAID uses Scalar Vector Graphics (SVG). SVG is the new
standard for images on the internet. In order to view these diagrams
you will need an SVG browser plugin. Such a plugin will enable you to
scroll images, zoom in/out without loss of precision. We recommend
that you install the free Adobe SVGViewer from
http://www.adobe.com/svg/viewer/install/main.html to enjoy the new
graphics experience.
ii) Any document can be converted to SVG using http://www.svgmaker.com

Eric
I enjoyed reading the draft of your book.  I might disagree with a few
points, but overall I think it is a valuable contribution to the field.

I wonder if you are aware of the Naked Objects framework?  It could be used
to illustrate a lot of your points rather well.  You can get it from
www.nakedobjects.org

Richard Pawson

P.S.  I am just completing my PhD thesis on the Naked Objects Pattern which
is essentially about making the domain model layer the only place where
software is developed.  All behaviour is encapsulated on the entity objects
(so there's no need for an 'application' layer) and the UI is merely a
direct reflection of the domain model (i.e. auto-generated).  It sounds
like it couldn't work, but it actually works very well.   It's the absolute
anithesis of your Smart UI anti-pattern.  If you're interested I'd be happy
to send you a copy of the draft.

----- Original Message -----

From: Richard Pawson

To: domaindrivendesign@yahoogroups.com

Sent: Wednesday, June 18, 2003 6:15 AM

Subject: [domaindrivendesign] Illustrating your ideas with Naked Objects

Eric
I enjoyed reading the draft of your book.  I might disagree with a few
points, but overall I think it is a valuable contribution to the field.

I wonder if you are aware of the Naked Objects framework?  It could be used
to illustrate a lot of your points rather well.  You can get it from
www.nakedobjects.org

Richard Pawson

P.S.  I am just completing my PhD thesis on the Naked Objects Pattern which
is essentially about making the domain model layer the only place where
software is developed.  All behaviour is encapsulated on the entity objects
(so there's no need for an 'application' layer) and the UI is merely a
direct reflection of the domain model (i.e. auto-generated).  It sounds
like it couldn't work, but it actually works very well.   It's the absolute
anithesis of your Smart UI anti-pattern.  If you're interested I'd be happy
to send you a copy of the draft.





To unsubscribe from this group, send an email to:
domaindrivendesign-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I'm not working on a book or a Ph.D., so I'm not sure I can
authoritatively join this thread, but I read both these books
recently (concurrently at times) and noticed the overlap of
ideas/practices.  I often felt the NO book was a concrete instance of
some of the general ideas in DDD.

I remember the name-collision in my head of the "Smart UI" concept,
since I thought of the Viewer in NO as a pretty-smart-UI, one that
could query objects and discover how and what to display from them.
But since it has no application smarts itself (it just knows who to
ask and how), there is no actual collision.  As Richard notes, the NO
Viewer and the DDD "Smart UI" are antithetical. So does that make NO
a DDD anti-anti-pattern? :)

Brett McHargue

--- In domaindrivendesign@yahoogroups.com, "pam rostal"
<pmrostal@a...> wrote:
> Richard,
>
> I read your book and found it fit well with work I was doing last
fall (got the book at OOPSLA).  We took a slightly different
approach, but the goal was essentially the same - let the users
control their own work.
>
> I am working on my Ph.D. as well, but from the social and
philosophical side of the user interface.  Would you be willing to
share a draft of your thesis?  Once mine gets a little farther, I'd
be more than happy to do the same if you'd like - it's probably a bit
far out for most people.
>
> Thanks,
> Pam
> pmrostal@a...
>   ----- Original Message -----
>   From: Richard Pawson
>   To: domaindrivendesign@yahoogroups.com
>   Sent: Wednesday, June 18, 2003 6:15 AM
>   Subject: [domaindrivendesign] Illustrating your ideas with Naked
Objects
>
>
>   Eric
>   I enjoyed reading the draft of your book.  I might disagree with
a few
>   points, but overall I think it is a valuable contribution to the
field.
>
>   I wonder if you are aware of the Naked Objects framework?  It
could be used
>   to illustrate a lot of your points rather well.  You can get it
from
>   www.nakedobjects.org
>
>   Richard Pawson
>
>   P.S.  I am just completing my PhD thesis on the Naked Objects
Pattern which
>   is essentially about making the domain model layer the only place
where
>   software is developed.  All behaviour is encapsulated on the
entity objects
>   (so there's no need for an 'application' layer) and the UI is
merely a
>   direct reflection of the domain model (i.e. auto-generated).  It
sounds
>   like it couldn't work, but it actually works very well.   It's
the absolute
>   anithesis of your Smart UI anti-pattern.  If you're interested
I'd be happy
>   to send you a copy of the draft.
>
>
>
>
>         Yahoo! Groups Sponsor
>
>
>
>   To unsubscribe from this group, send an email to:
>   domaindrivendesign-unsubscribe@yahoogroups.com
>
>
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.

I am aware of the Naked Objects framework, but don't know a lot
about it. It is definitely an attempt to drive design from the
domain.

When I read about it, I found it an exciting idea, but I had a few
reservations. The biggest was the idea of generating the UI from the
business objects. I don't think it is the problems that arise in
a "Smart UI". In fact, Naked Objects DOES separate UI from the
business objects, in the form of those generic views, and so on. The
UI in NO is less "smart" in the sense I meant than it is in most of
my designs. (My name Smart UI is ok in the context of my book, but
in a broader context maybe something like "Domain-Savvy UI" would
have been better. A quite generic UI element can be very smart.)

But I think that the UI often needs to be streamlined for user tasks
in a way that doesn't break down as one object--one UI element. (It
would be interesting to have somebody expert in UI design join this
discussion.) Something in the system has to make this reach, and in
NO I'm afraid it will be the domain objects. Perhaps the UI could
reach part way by creation of a specialized viewer. At this point,
my lack of detailed knowledge (not to mention hands-on experience)
of NO prevents me from saying much. But those were the concerns I
had.

Eric

--- In domaindrivendesign@yahoogroups.com, "Richard Pawson"
<rpawson@c...> wrote:
> Eric
> I enjoyed reading the draft of your book.  I might disagree with a
few
> points, but overall I think it is a valuable contribution to the
field.
>
> I wonder if you are aware of the Naked Objects framework?  It
could be used
> to illustrate a lot of your points rather well.  You can get it
from
> www.nakedobjects.org
>
> Richard Pawson
>
> P.S.  I am just completing my PhD thesis on the Naked Objects
Pattern which
> is essentially about making the domain model layer the only place
where
> software is developed.  All behaviour is encapsulated on the
entity objects
> (so there's no need for an 'application' layer) and the UI is
merely a
> direct reflection of the domain model (i.e. auto-generated).  It
sounds
> like it couldn't work, but it actually works very well.   It's the
absolute
> anithesis of your Smart UI anti-pattern.  If you're interested I'd
be happy
> to send you a copy of the draft.

"brettmchargue" <workBrett@m...> wrote:
> I'm not working on a book or a Ph.D., so I'm not sure I can
> authoritatively join this thread, but I read both these books
> recently (concurrently at times) and noticed the overlap of
> ideas/practices.  I often felt the NO book was a concrete instance
of
> some of the general ideas in DDD.

Please do participate. I don't have a Ph.D. either.

I think you are right: Naked Objects is an attempt at a concrete
application of domain-driven design (the idea, as distinct from the
book.) As such, I find it hopeful.

> I remember the name-collision in my head of the "Smart UI"
concept,
> since I thought of the Viewer in NO as a pretty-smart-UI, one that
> could query objects and discover how and what to display from
them.

Yes, as I mentioned in my previous post, maybe I should have called
it Domain-Savvy UI. Too late now. The NO viewers are a UI layer,
with no domain logic. This follows the Layered Architecture. My
worry is about user tasks that don't map conveniently to domain
objects, and the effect that will have on the model.

I think this is related to the Use-Case thread, also.

> Viewer and the DDD "Smart UI" are antithetical. So does that
> make NO a DDD anti-anti-pattern? :)

I don't want to go down that path! :)

I think the key to placing use cases within domain-driven design is
the "ubiquitous language". The model is our developing understanding
of the domain we're operating in. The use cases describe some task
we want to perform in that domain. To join the two, we can write the
use cases in the language of the model. If that language is truly
ubiquitous, it will be the basis of all documents and conversations
relating to the domain.

The model evolves, so the use cases have to be revised as well. If
the model is developing in a useful direction, then the use cases
should be easier to state in the new ubiquitous language.

If you have a use case called "Approve Purchase Order", is that
stated in the ubiquitous language? Does the model have an object
called Purchase Order? Is there an object or operation
called "approve" or "approval"? Within the detail of the use case, I
would look at each statement that way. If I found a disparity (and I
often would) then I would resolve it in one of two ways.

1. Rewrite the use case to use model terminology. This has the
benefit of reducing ambiguity. It will usually make it more concise.
(If it doesn't, then consider option 2.)
2. If the use case seems more communicative than it would in the
language of the model, look for terms that might indicate implicit
concepts and go to work improving the model.

This sounds like a lot of work, and it is. But it is less work than
having use cases and models charging off in different directions.

Of course there are things in a use case that are out of the scope
of the model (stake-holders, some sequences of events, all that
stuff related to the program rather than the domain of the program),
but I suspect it is the point of connection between the use case and
model that generates confusion.

I see use cases as being central to the design of the application
layer and to some extent the UI layer. But all of this is in the
context of understanding the domain we are operating in.

Sorry I've been so slow to respond to this.

By the way, do we have anyone here who works in usability, or UI
design?

Eric

--- In domaindrivendesign@yahoogroups.com, "robert_s_ddd"
<robert.schulz@s...> wrote:
>
> Domain driven design addresses the modeling/structuring of
> the "business object tier" of a system ... developing a
> deeper understand about the domain and modeling the
> software around the "guts" of the domain ... I can see how
> this results in a flexible design - the model mirrors what's
> happening in the real world and if things change it maps
> nicely into the model making the change "natural", easier,
> i.e. the design is flexible.
>
> I am interested in some thoughts / comments on is how this
> relates to functional application design: One approach to
> get this right is the use case driven approach - trying to
> work out what users actually want to accomplish with the
> system and using this as the driving force for the modeling.
> Use cases often often cross multiple "business objects", so if
> you use them to drive the design, you end up with different
> underlying model than using the DDD approach - the result
> is software which is tailored to user needs but is less
> flexible.
>
> It seems you need to need both approaches - use cases for the
> application flow (and presentation layer follows from there)
> and domain analysis for the business logic layer (and data
> layer follows from there). Question is, which model should be
> the driving  force? Also, if you need both models, how do you
> synch them up?
>
> I guess one idea is to use the use case model to verify the
> domain model?
>
> Am very interested in comments, insights ...
> Cheers,
>
> Robert.

Eric wrote:

>My worry is about user tasks that don't map conveniently to domain
>objects, and the effect that will have on the model.

This is a common and very understandable reaction to the Naked Objects
concept.  To begin with it seems unlikely that all user actions would map
onto objects, but when you try it out this is much less of a problem than
it seems.

When we first started four years ago, we found ourselves writing 'helper
methods' on some objects, which didn't really naturally belong.  But as the
generic capabilities of the framework have been extended, we find the need
for these helper methods has reduced.

A good example is having a method on a Customer object called
CreateNewBooking (for that Customer).  This is convenient to the user but
arguably not a natural responsibility of Customer.  However, assuming that
there is a bi-directional association between Customer and Booking (as is
usually required) then the latest framework automatically provides the
functionality to create a new Booking ready-associated with the Customer
just by right clicking on the grey 'hole' at the bottom of the collection
of Bookings visible inside the Customer.

Our experience suggests that far from corrupting the model, the discipline
of forcing all user actions to be behaviours on domain objects, forces much
better domain modelling.  For example, Dan Haywood and I recently did a
comparative implementation of a four-layer Java application with a Naked
Objects implementation.  (We were very rigorous in our technique to avoid
any bias in favour of Naked Objects).  Not only was the latter much more
efficient in coding terms, but it also proved much easier to modify than
the conventional 4-layer model (which had an 'application' layer) in
response to unforeseen changes in business requirements.  If anyone would
like to see the data on that experiment, please email me direct.


Richard

I'm afraid that is a complicated question. I suppose the short answer is
yes, domain-driven designs are done in J2EE, although it is a complicated
framework, and you could easily imagine a more supportive one. In practice,
domain-driven projects using J2EE pick and choose the features of the
framework that they really need. One project I worked with chose not to use
Entity Beans, but got a lot of benefit from Session Beans. The J2EE folks
even have a pet name, "POJOs" (Plain Old Java Objects), for elements of
their design for which they choose a light-weight implementation.
Typically, these are  encorporated into the framework at a larger
granularity, such as an entity bean that provides a large-grained service.

Could you quote more of the statement that prompted the question?

Eric

Original Message:
-----------------
From: henryk mozman henrykmozman@...
Date: Sun, 22 Jun 2003 13:19:34 -0700 (PDT)
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Domaindrive and J2EE


Hi,

I am a newbie to the world of domaindriven.

I have come across a vendor statement to the effect that J2EE does not
offer much support to the domain-centric type of applications.

Should this be considered a true statement ?

'Henryk


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

It is interesting. I like the emphasis on the model, and the
attitude that you refuse to compensate for a weak model with a
complicated application layer. That is a slippery slope, and you
guys are staying far from it. I also think that your UI layer is
very distinct, with little domain logic but a lot of display
capability built in. (So maybe your objects have some underwear on,
anyway.)

I don't have either real expertise in UI design or hands-on
experience with Naked Objects, so I can't really reach conclusions.
I haven't even had the experience of using an app written in naked
objects. (I have used earlier domain-object oriented UIs that did
not work well, but I won't tar you with that brush. It sounds like
you're concious of those pitfalls, at least.)

I hope there will be multiple, successful approaches to domain-
driven design. I am glad this approach is being tried, and it sound
like it is still evolving and being improved. I'll try to learn a
bit more about it when I get a chance.

Eric

Hi, Panayotis.
Thank you for posting these interesting questions. In future, I'd
like to ask people to avoid MS Word documents, because they cause
problems for some people. I believe if you send an HTML formatted
email to the group it will display correctly and allow embedded
diagrams.

So, I have a number of thoughts about your questions, but I realized
that, for me to think through the issue, I needed to know more about
the intended use of these objects. I know that you are collecting
sets of measurements, and are concerned that all measurements be of
the same kind. Is this for a data collection system? For scientific
experiments? Monitoring a chemical plant? Tracking stocks? Is there
actually a possibility of kilograms and Euros being combined in the
same collection or was that just an explanatory example? What will
happen to these values after they have been collected? Will they be
converted to the one unit basis and then manipulated? Will they be
charted?

I need some context to think this through properly, because the
choice of a model is based on its utility in a particular situation.

Thanks,
Eric


--- In domaindrivendesign@yahoogroups.com, "Matsinopoulos Panayotis
(panayotis.matsinopoulos@i...)" <panayotis.matsinopoulos@i...> wrote:
>

I'm afraid that is a complicated question. I suppose the short answer is
yes, domain-driven designs are done in J2EE, although it is a complicated
framework, and you could easily imagine a more supportive one. In practice,
domain-driven projects using J2EE pick and choose the features of the
framework that they really need. One project I worked with chose not to use
Entity Beans, but got a lot of benefit from Session Beans. The J2EE folks
even have a pet name, "POJOs" (Plain Old Java Objects), for elements of
their design for which they choose a light-weight implementation.
Typically, these are  encorporated into the framework at a larger
granularity, such as an entity bean that provides a large-grained service.

Could you quote more of the statement that prompted the question?

Eric

Original Message:
-----------------
From: henryk mozman henrykmozman@...
Date: Sun, 22 Jun 2003 13:19:34 -0700 (PDT)
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Domaindrive and J2EE


Hi,

I am a newbie to the world of domaindriven.

I have come across a vendor statement to the effect that J2EE does not
offer much support to the domain-centric type of applications.

Should this be considered a true statement ?

'Henryk


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .




To unsubscribe from this group, send an email to:
domaindrivendesign-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Eric,

I recently downloaded your book and have been reading through it as
time permits. I am a newbie when it comes to OO*. From the books and
articles that I have been reading, your book is one of the very few
which talks about the importance of domain design.

My problem with methodologies like Agile and XP is that they tend to
ignore the big picture in a hurry to get into design and
development.  "Traditional" methodologies like IE lay a huge
emphasis on understanding the AS-IS and the TO-BE of a business
process and identifying business process re-engineering requirements.
The Agile/XP processes are geared towards a "learn as you go
long" approach. This lack of "big up-front" leads to fractured
domain models. The cost of re-factoring a domain model is huge (as
you have also noted in your share-pie example) and the costs increase
with every iteration.

Some may claim that this problem can be mitigated by
implementing "enterprise patterns" (e.g. Fowler). The problem
with patterns approach is that a pattern solution can be applied only
after the problem is identified as a pattern.


Hemant Sahgal

Hi, Hemant. Thanks for the comments.

I agree and disagree.
True, refactoring domain models can be very expensive. But costs
don't necessarily increase with each iteration. Keeping that cost
down is one of the benefits of a supple design.

Also, as expensive as refactoring is, it can be a lot less expensive
than sticking yourself with a naive, early model and design. The
learning curve is so steep on a good software development project
that the models possible at later stages will be incomparably more
useful than those proposed early on. I change domain designs, and
change them and change them. And they become more supple along the
way, which helps control the cost -- some.

Where I do part ways with many XPers (though I am by no means alone)
is on the amount of work I'm willing to put in to have model objects
that actually carry meaning, rather than taking the most direct path
to implementing the functionality of the first iteration. Everyone
agrees that duplication is unacceptable. For me, it is also
unacceptable not to have your current understanding of key parts of
the domain reflected clearly in the code.

I view it as an essential part of development, even in the first
iteration, to capture the knowledge related to that iteration's
functionality and crunch it into the model. Then, in the second
iteration, your eyes will be opened and you'll end up refactoring
those old objects. Then in the third iteration you'll REALLY
understand them and you'll refactor them. Or at least you though you
really understood them, but then in the sixth iteration...

Ah, but you can't do that for everything in the system. Hence all the
talk in Chapter 15 about the core domain and so forth. Only parts of
the system deserve that kind of investment. Others merely have to be
good enough, and will (we hope) stabilize.

I do agree with you on the importance of having a big picture. I
think that is what the "system metaphor" of XP is reaching for,
although it only covers a few cases. So Part IV of the book is all
about the big picture. But that big picture has to evolve, too. (And,
yes, it is expensive.)

Eric

My problem with methodologies like Agile and XP is that they tend to
ignore the big picture in a hurry to get into design and
development.

Dan/Eric,

Let us consider a Sale event in an enterprise. Logistics will see a
Sale event as an invoice; Accounts will see the same event as a debit
entry for the customer; Sales will see it in terms of an entry
towards meeting their sales target; Stores will see it as a reduction
in stocks; Marketing will view it in terms market penetration etc.
Similarly, other departments will have other views of the data.

The point to note is that all these are very different views of the
same event. The data underlying the event is the same. How this same
data is viewed by different parts of the enterprise is very different.

Getting into design/development very quickly without enumerating,
examining and putting together all the different views can lead to
very process/department centric multiple design models and it becomes
very difficult to assimilate and reconcile all these different views
into a single model late in development.

I am not saying that this problem is unique to OOAD but I think that
going into design/development very early increases the chances of
missing the "big picture" till very late in the development cycle.

"Do you believe that somewhere in the scheme of things there is a
solution to the relation between design details and how those details
can best be fit together to compose an optimum big picture?"

A good Information Modeler will be able to reconcile these views into
a single model "up front". There will be mismatch between
the "conceptual model" and the "physical model" but as long as the
physical model is traceable from the conceptual model it is ok. Which
is why in structured programming the code is important but the core
data model is sacred.

"Where have you looked to date for such a possible solution to this
relation between the development of a design into a satisfactory
whole picture?"

Here are tow places where I have found some good stuff. Good off the
shelf conceptual models can be found/derived from David Hay, "Data
Model Patterns: Conventions of Thought". These models demonstrate
what a good information modeler can do. I have read some of Fowler's
writings (those that are available online).

Unfortunately, most books and articles on OO* focus on very (what I
would like to call) micro-problems requiring code-design solutions
rather than demonstrating the solving of domain problems.

If you know of some other good sources please point them out for me.

Hemant

Hemant, thanks for providing a concrete example. That will help keep
us on track.

Let's talk about the question of how that modeler would reconcile
those views and what form that big picture might take. (We could
probably have a pretty interesting debate about the tradeoffs of
upfront design, but although I have my opinions on that subject,
domain-driven design should work in any process that provides
adequate means of learning about the domain and has feedback.) So,
here are some ways of initially approaching the issue with the tools
in the book.

The first thing I think of with the example you gave is a "context
map" (discussed in Chapter 14). The different departments have
different models. They see the same thing and it means something
different to them. We have some integration needs, so we have to
decide what the relationship of the models in those different
departments is going to be. For me, that means mapping out the way
things ARE, first. Then at least people will be able to have rational
conversations.

In this case, it sounds like we might have a "shared kernel", a
certain part of the model that everyone agrees on, but which they use
in their subsystems in different ways. The "Sale" event is the main
element of that kernel.

Trouble may arise from the teams' lack of recognition that they are
operating in different contexts, where terms mean different things,
yet they are sharing one object. So the logistics people start
tacking on invoice properties and behaviors, the accounts department
starts making it act like a debit, and so on. Optimistically, they
will end up with a bloated jumble. More likely, they will step on
each other and make buggy, self-contradictory software.

On the other hand, if they agree that "Sales Event" (or was
it "Sale") is shared, and work to keep it in common, they will end up
trimming that shared object down to the essence of what everyone sees
as that basic event. Then they will probably create an "Invoice"
object that has a reference to a "Sale". They'll create an "Account
Entry" that references a "Sale", and so on. At this point, we have
minimal, but rational, integration. We have the beginnings of a big
picture (the context map). We have people talking to each other with
clear context for their communication, so that analysis will be more
effective if they take steps to find a deeper model. (After all, this
is just something off the top of my head, and I don't have a deep
understanding of their situation.) They might find a way to unifying
their various models, but not necessarily.

When these things are eventually implemented, I would expect to see a
recognizable "Sales" object in each of those subsystems. It might be
implemented differently, especially if different technologies are
used in different subsystems, but it should be semantically
equivalent, so that translation is trivial. I expect this
correspondence between model and implementation to be very close, or
else the analysis that goes into the model does not give confidence
about the correctness of the software. This is what I mean by
a "model-driven design". Of course, many implementations might map to
the same model, but I do not mean by this just traceability. I mean
an obvious, quite literal mapping between concept and software
artifact.

Eric

Thanks for the link. I looked through it. It is a slide presentation,
and so it is risky to interpret without the having heard the talk
that goes with it. With that caveat, I'll venture a few comments.

Their statement that J2EE doesn't provide much support for domain-
driven design has the heading "A Contentious Conjecture". And then
they spend the rest of the talk telling how to do just that. Since
J2EE came along, people have been experimenting with ways of making
it work with models. This presentation describes one approach which,
if I interpret the slides correctly, is basically:

- Use J2EE to implement coarse-grain components (specifically,
stateless session beans)
- Use plain old Java objects to implement the domain model.
- Let the components call the Java objects to delegate the actual
logic that is being requested of them by the client.

This is becoming a pretty main-stream view. Once people got used to
the idea of not relying on J2EE to implement their domain objects,
things did clarify.

Actually, it looks like it was probably a good presentation.

Eric


--- In domaindrivendesign@yahoogroups.com, henryk mozman
<henrykmozman@y...> wrote:
> Eric,
>
>
> Thanks for the explanation.
>
> The statemetn that prompted this question I found it in the
following document:
>
> http://www.austinjug.org/media/Keiron_Domain_Model_Centric.pdf
>
>
> 'Henryk
>
> "eric@d..." <eric@d...> wrote:
> I'm afraid that is a complicated question. I suppose the short
answer is
> yes, domain-driven designs are done in J2EE, although it is a
complicated
> framework, and you could easily imagine a more supportive one. In
practice,
> domain-driven projects using J2EE pick and choose the features of
the
> framework that they really need. One project I worked with chose
not to use
> Entity Beans, but got a lot of benefit from Session Beans. The J2EE
folks
> even have a pet name, "POJOs" (Plain Old Java Objects), for
elements of
> their design for which they choose a light-weight implementation.
> Typically, these are  encorporated into the framework at a larger
> granularity, such as an entity bean that provides a large-grained
service.
>
> Could you quote more of the statement that prompted the question?
>
> Eric
>
> Original Message:
> -----------------
> From: henryk mozman henrykmozman@y...
> Date: Sun, 22 Jun 2003 13:19:34 -0700 (PDT)
> To: domaindrivendesign@yahoogroups.com
> Subject: [domaindrivendesign] Domaindrive and J2EE
>
>
> Hi,
>
> I am a newbie to the world of domaindriven.
>
> I have come across a vendor statement to the effect that J2EE does
not
> offer much support to the domain-centric type of applications.
>
> Should this be considered a true statement ?
>
> 'Henryk
>
>
> ---------------------------------
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
>
> Yahoo! Groups SponsorADVERTISEMENT
>
> To unsubscribe from this group, send an email to:
> domaindrivendesign-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
> ---------------------------------
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!

-----Original Message-----
From: Eric Evans [mailto:eric@...]
Sent: Monday, June 23, 2003 1:18 AM
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Re: Aggregates and References to Invariants

Hi, Panayotis.
Thank you for posting these interesting questions. In future, I'd
like to ask people to avoid MS Word documents, because they cause
problems for some people. I believe if you send an HTML formatted
email to the group it will display correctly and allow embedded
diagrams.

So, I have a number of thoughts about your questions, but I realized
that, for me to think through the issue, I needed to know more about
the intended use of these objects. I know that you are collecting
sets of measurements, and are concerned that all measurements be of
the same kind. Is this for a data collection system? For scientific
experiments? Monitoring a chemical plant? Tracking stocks? Is there
actually a possibility of kilograms and Euros being combined in the
same collection or was that just an explanatory example? What will
happen to these values after they have been collected? Will they be
converted to the one unit basis and then manipulated? Will they be
charted?

I need some context to think this through properly, because the
choice of a model is based on its utility in a particular situation.

Thanks,
Eric


--- In domaindrivendesign@yahoogroups.com, "Matsinopoulos Panayotis 
(panayotis.matsinopoulos@i...)" <panayotis.matsinopoulos@i...> wrote:
>



To unsubscribe from this group, send an email to:
domaindrivendesign-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.

Eric,

I am fully for domain driven design!

...domain-driven design should work in any process that provides
adequate means of learning about the domain and has feedback...
...We have some integration needs, so we have to decide what the
relationship of the models in those different departments is going
to be. For me, that means mapping out the way things ARE, first.
Then at least people will be able to have rational
conversations.

Isn't that what IE is all about - domain driven analysis and
design?

...it sounds like we might have a "shared kernel", a certain part
of the model that everyone agrees on...

Generally, the "shared kernel" is hidden from the users. There is
a need to bring it out into the open and this can happen only with
integrating the models very early or trying to build an enterprise
model to begin with.

My problem is how to reconcile the domain design(s) with the big
picture. Of the couple of books on OO that I have read, yours is
the only one which advocates tending to the domain model. Most
books teaching OOAD tend to favour Agile/XP methodolgies. Most
books tend to make a direct jump from use cases to object
interaction to class diagrams. Others talk about the domain model
but say that it should be discarded after a couple of iterations
[Larman - Applying UML and Patterns; Scott Ambler - Agile Modeling
site].

hemant



___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com

-----Original Message-----
From: hemant sahgal [mailto:hsahgal@...]
Sent: Thursday, June 26, 2003 2:19 AM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] Re: Big Picture

Eric,

I am fully for domain driven design!

...domain-driven design should work in any process that provides
adequate means of learning about the domain and has feedback...
...We have some integration needs, so we have to decide what the
relationship of the models in those different departments is going
to be. For me, that means mapping out the way things ARE, first.
Then at least people will be able to have rational
conversations.

Isn't that what IE is all about - domain driven analysis and
design?

...it sounds like we might have a "shared kernel", a certain part
of the model that everyone agrees on...

Generally, the "shared kernel" is hidden from the users. There is
a need to bring it out into the open and this can happen only with
integrating the models very early or trying to build an enterprise
model to begin with.

My problem is how to reconcile the domain design(s) with the big
picture. Of the couple of books on OO that I have read, yours is
the only one which advocates tending to the domain model. Most
books teaching OOAD tend to favour Agile/XP methodolgies. Most
books tend to make a direct jump from use cases to object
interaction to class diagrams. Others talk about the domain model
but say that it should be discarded after a couple of iterations
[Larman - Applying UML and Patterns; Scott Ambler - Agile Modeling
site].

hemant



___________________________________________________
Click below to experience Sooraj Barjatya's latest offering
'Main Prem Ki Diwani Hoon' starring Hrithik Roshan,
Abhishek Bachchan & Kareena Kapoor http://www.mpkdh.com



To unsubscribe from this group, send an email to:
domaindrivendesign-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

 

Suppose we have a MeasurementUnitDomain (MUD) class, instances of which may be "Time", "Volume", "Currency". Any instance of this class contains MeasurementUnit(MU) objects. Examples of MUs are "seconds", "hours", "minutes" for the "Time" MUD, or "bits", "bytes" for the "Volume" MUD, or "Euro", "USD" for the "Currency" MUD. I have chosen to model this as follows:

 

 

As you can see, I have set the stereoptypes using your pattern language. I think that I have done it correctly.

I was trying to understand whether the MU is an ENTITY or a VALUE OBJECT. I think that it is an ENTITY because it is uniquely identified, even only in the context of the owning MUD. It has a unique "code" for the particular MUD that it belongs. Moreover, I set "ENTITY-AGGREGATE" on MUD because I think it constitutes the ROOT ENTITY of an AGGREGATE that contains two classes, the MUD and the MU. Any MU instance cannot exist on its own unless the corresponding / owning MUD exists.

 

Am I correct?

---------------------------------------------------

This is not a classic case of entities, because they are all immutable, and we could have more than one copy of a Measurement Unit probably without harm. But I think they still fit the definition, because, as you point out, they have identity.

However, the direction of that arrow between MeasurementUnitDomain and MeasurementUnit seems backwards to me or perhaps needs to be bidirectional. (Here is where knowing application requirements comes in.) A MeasurementUnit aught to know what sort of thing it is, I would think.

Which makes me suspect the aggregate (MUD contains MU).

--------------------------------------------------------

 Then, I tried to model a list of values and link it somehow to the measurement units. I need to say that each value in the list has to be expressed in a measurement unit. I did the next:

 

 

As, I have read in your book, "...The root is the only member of the AGGREGATE that outside objects are allowed to hold references to, ...", which means that my design violates this principle, since "Value" holds reference to "Measurement Unit".

 

It is true that I have faced this problem many times and I did it just like that. What is wrong with this approach? How should I do it to be correct according to the principle that your book presents? 

-------------------------------------------------

And at this point it is clear that the MU is not contained in the MUD aggregate. Then you are rid of that violation. The issue of a MU having no meaning outside a MUD sounds like a call for a reference from MU to MUD.

-------------------------------------------------- 

 

Problem 2:

 

                The second problem is a step further to the 1^st one. Suppose that, in addition to the 1^st requirement, which states that each "Value" has to be of a "Measurement Unit", we do not want to have "Values", in the same "ListOfValues", that have "Measurement Units" from different "Measurement Unit Domains", but that all the "Values" have to be of the same Measurement Unit Domain.

 

I did the next:

 

 

This model however DOES NOT prevent the developer to create instances of "Values" and assign them to "Measurement Units" of different "Measurement Unit Domains".

-----------------------------------------------

Ah, I love constraints. You need to make that constraint explicit in the model.

1. The ListOfValues aggregate enclosing Value seems right, and this is the level at which this constraint applies.

2. The ListOfValues already knows which MUD its Values belong to, so, as aggregate root, it should be capable of enforcing the constraint.  

But to do that effectively, Value needs to know its MUD, which means MU needs to know. Again, that arrow between MUD and MU is in the way.

 

(By the way, Value is definitely a Value Object. That was easy wasn't it!)

-------------------------------------------------

 

How can I prevent from this? Will the FACTORY solve my problem? Can I have the "ListOfValues" constructor "protected" and only let another object like "ListOfValuesFactory" to create "ListOfValues" objects like the next:

 

 

 

This method might throw an Exception whenever you try to create a "ListOfValues" and giving an array of "Values" that are assigned "MeasurementUnits" that do not belong to the "MeasurementUnitDomain", given as input argument too.

---------------------------------------------------

This constraint is an important property of ListOfValues, and it would be better to keep it there if you can. Besides, is ListOfValues immutable? It seems like it should be possible to add an item. Or do you always create a list fully formed? It seems more natural to me to create an empty ListOfValues and add() or addAll() to populate it. 

 

So, to sum up the changes I would make:

1. I'd not put the MU within the aggregate of the MUD.

2. I'd make the association between MU and MUD point the other way or make it bidirectional (depending on app requirements, but the requirements you've mentioned, and the meaning of the concepts themselves, demands the other direction).

3. I'd give ListOfValues responsibility for enforcing the constraint that all its Values are from the same MUD.

 

When I say that I'd like to know the application, I mean concretely. Is this used to collect measurements from a hear rate monitor? Is it used to track currency trades? And is there any actual scenario that would end up with a mixture of units in the list?

 

-Eric