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

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 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

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 can't see the page either.  I wonder which domain layer of the site is
having problems?  ;-)

--jk

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'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

At 9:48 PM +0000 11/16/02, Eric Evans wrote: (excerpted from below)
>Now, I don't want to say that the user has to be shown an unadorned
>view of the domain model. That would definitely not be convenient in
>most cases. What I do think is that the model underlying the UI is
>the domain model. This is a good example. If bookmarks are actually
>files, then expose this to the user.

Would this be something like what you mean?

The average user would think of bookmarks as named URLs stored in a
list gotten to by the Bookmarks menu entry. However, when the
file-open error happened, the message would look like this:

Explorer tried to create the bookmark 'RUP: Domain model'.
That meant creating a file named 'RUP: Domain model' in folder 'blah'.
But these characters are not allowed in a file name: :\"^'.
Please change the bookmark name so that it doesn't contain those characters.

That way, the user gets a bit of "just in time" education about the
underlying domain model when an error happens.

====

I'm trying to support that style, while making it relatively
unobtrusive to the programmer. When  programmers are reading code
that implements some function, they want to see as little about error
handling as possible. I could separate error handling into
aspect-style wrappers, but I find that doing error checking only on
function-call boundaries is too coarse-grained. Either the
error-handling is bad (because the messages to the user can't have
the right information, like the values of locals) or you have to make
artificial divisions between functions so that you have a place to
hook on wrappers (but those divisions are inexplicable to someone not
thinking about error handling, so error handling again distracts the
programmer, just in a more obscure way).

I'm curious about people's reaction to the following scheme.

Each user interface command hands its name and argument off to an
"attempt" method. That method wraps a call to the implementation of
the UI command with a try-catch block. The  implementation method is
oblivious to all that error-handling setup. For example, I recently
changed the implementation of the "pause_day" command in an
application I'm working on. The (Ruby) code looks like this:

          def pause_day(when_to_pause = "now")
            pause_time = DesiredTime.at(checking_time_from(when_to_pause))
            paused = @session.pause_without_resumption(pause_time)
            @quick_start_action = proc {
              start(paused.full_name)
            }
            pause_description(paused, pause_time)
          end

This looks unconcerned with error-handling because it is. All
checking is done on the server side (by lower level code) and there
are no translations the user needs to know about.

When a command needs to make a translation, it uses a "step" method.
That looks like this:

          def start_day(when_to_start = "now")
            step(:start_background_job) {
              ... stuff that starts the day
            }
          end

Step pushes the name of the step (and any relevant arguments) onto a
stack, executes the code within its curly-braces, then pops the
stack. My hope is that it's relatively easy to ignore the steps,
consider them just syntax, when reading the code to see what it
normally does.

Error checking looks like this:

        def start_background_job(desired_time)
          whine_if (@active_job_manager.any_active?,
                            :start_background_but_jobs_are_active)

          background = @jobs.background_job
          ...

Whine_if throws an exception if its condition is true. The exception
bundles up the name of the complaint
(:start_background_but_jobs_are_active) and any relevant arguments
(none, in this case). The exception travels up the call stack, across
the network connection, to the client, up its stack and finally gets
caught by the original attempt() method. That method now has a series
of name+arguments:
1) the original attempt.
2) a stack of steps taken on the way to a place an error happened.
3) the complaint.

It takes those and translates them into a message to the user. It
tacks on a suggestion if there's one that applies to that attempt and
that complaint.

As a little refinement, it filters out steps that are known not to be
relevant to a particular complaint. So, if it was discovered that the
URL was bad within the bookmark-name-to-URL step, you wouldn't get:

    Explorer tried to create the bookmark 'RUP: Domain model'.
    That meant creating a file named 'RUP: Domain model' in folder 'blah'.
    But the URL does not begin with "http".
    Please pick a different URL.

People don't much like non-sequiters from computers.

--

-----
Brian Marick
Consulting, training, contracting, and research
Focused on the intersection of testing, programming, and design
marick@..., marick@...
www.testing.com, www.visibleworkings.com

"Act always so as to increase the number of choices." -- Heinz von Foerster

Good news. The end is near. In a month or so, I'll be making a final
draft and sending it off to the publisher. This means that not
everything I might like to change will get changed. I must focus on
the most important weaknesses.

I have my own ideas about what absolutely must be changed, but I know
I have blind spots. So I'm asking you, who have read the book or are
reading it, to help me by nominating candidates. If you could have me
change **just one or two things**, which would they be?

A discussion among the people here would probably shed a lot of
light. Do it soon, since there isn't much time left.

Thanks,
Eric

>Actually, I guess I need to make sure that a point this important is
>made in bold print somewhere, don't I.

When you made your point, I realized it was implicit in what you
had said.  However, even after having read your book twice, it
was not obvious to me that you would say that.

-Ralph

Hmmm. I thought I had made the point in the Model-Driven Design
pattern. I did talk about the problems of separate "analysis models".
But maybe if I use this example and make a direct statement...

Actually, I guess I need to make sure that a point this important is
made in bold print somewhere, don't I.

Eric

--- In domaindrivendesign@y..., Ralph Johnson <johnson@c...> wrote:
> This is a very good point, and a good example to make that point.
> You should include it in your book, because your book does not now
> make clearly the point that your belief in one model applies to
> the implementation, as well.  Unfortunately, I don't know where you
> should put this discussion.

>One of my strong opinions is that we should be working with only one
>model (within any single context, as discussed in Chapter 14). Most
>of my rants in the book on this topic point out the problems of
>having separate analysis models and design models, but here we have a
>problem arising from a different pair of models: the user model and
>the design/implementation model.

>Now, I don't want to say that the user has to be shown an unadorned
>view of the domain model. That would definitely not be convenient in
>most cases. What I do think is that the model underlying the UI is
>the domain model. This is a good example. If bookmarks are actually
>files, then expose this to the user. Not only will it be less
>confusing with error messages, the user can then leverage what he
>knows about the file-system to deal with bookmarks. He can go find
>them in the file browser and organize them, for example, rather than
>using awkward tools built into the browser. Why make the user learn a
>new model when the programmers felt the old model was good enough?

>Now, if bookmarks were actually being stored in a different way, say
>in a datafile, they could have their own rules. Those rules, it seems
>to me, should be the naming rules that apply to websites. That would
>be a single model, again, that tells the user that everything they
>know about naming websites applies to bookmarks.

This is a very good point, and a good example to make that point.
You should include it in your book, because your book does not now
make clearly the point that your belief in one model applies to
the implementation, as well.  Unfortunately, I don't know where you
should put this discussion.

-Ralph

This is a good topic for discussion. Brian actually brought this
issue up with me and I asked him to repost it here because I'd like
to hear what others have to say. Here are some of my thoughts.

> For example, a user of Internet Explorer thinks of bookmarks as
names
> for URLs that persist from session to session. The implementation
> thinks of bookmarks as files that contain URLs. That's a problem if
> you can persuade IE to try to create a bookmark called "RUP: Unit
> Testing", because that was not a valid filename on DOS. The error
> message is in terms of filenames, which I think is completely
> bewildering to too many users. (For more on this bug, see this:
> <http://www.visibleworkings.com/papers/ready-to-hand-bugs.pdf>.)

One of my strong opinions is that we should be working with only one
model (within any single context, as discussed in Chapter 14). Most
of my rants in the book on this topic point out the problems of
having separate analysis models and design models, but here we have a
problem arising from a different pair of models: the user model and
the design/implementation model.

Now, I don't want to say that the user has to be shown an unadorned
view of the domain model. That would definitely not be convenient in
most cases. What I do think is that the model underlying the UI is
the domain model. This is a good example. If bookmarks are actually
files, then expose this to the user. Not only will it be less
confusing with error messages, the user can then leverage what he
knows about the file-system to deal with bookmarks. He can go find
them in the file browser and organize them, for example, rather than
using awkward tools built into the browser. Why make the user learn a
new model when the programmers felt the old model was good enough?

Now, if bookmarks were actually being stored in a different way, say
in a datafile, they could have their own rules. Those rules, it seems
to me, should be the naming rules that apply to websites. That would
be a single model, again, that tells the user that everything they
know about naming websites applies to bookmarks.

There were other good issues raised in your message, but I wanted to
make my point about the risks of trying to map between multiple
models within the same context.

-Eric

Very interesting points, Chris. I'm sorry I've been so slow in
responding. I got a little buried preparing for OOPSLA, etc.

On reading your message, I realized I hadn't quite made my point
clear. The distinction between Entities and Values is a semantic
distinction. My extensive discussion of performance issues was
intended to explore the consequences of certain model choices.

> There also seems to be some constraint on
> re-usablility - as a different application may well want to
> represent the
> object as a value and so cannot re-use the first design that takes
> it as an entity.
Yes, if one system views an object as a value and the other views it
as an entity, they will be difficult to integrate, because they have
different semantics in their models. This was a point I had intended
to make, but it may not have come through very clearly. If two
systems want to share an object, they had better agree on whether it
is an entity or a value. In the entities section, I pointed out how a
Customer object might take quite different forms on different
systems, but still have the same identity and allow the exchange of
data.

Of course, the fine-grain breakdown could be different. (I tend to
keep entities very lean, and attach values to describe them partly
for this reason, but the difficulty still arises.) For example, if
the crayon's ownership is being tracked (if I understand your point)
then you are right, the crayon is an entity. The color could be
modeled as an attribute of that entity (a numerical color value) or
as a value object associated with that entity. The latter would be a
more explicit model that communicates the semantics better.

But I am a little suspicious of application independent designs. When
people start tracking the ownership of crayons just on principle or
just in case, I think it actually obscures understanding. If someone
has figured out that noone cares which crayon is which, it is an
important piece of knowledge that should be reflected in the model.
It also keeps things simpler. If this turns out to have been a wrong
decision (because some system that we have to integrate with does
care) then the model will have to be changed.

Did that clarify my meaning? And, if so, do you agree?

By the way, if you are interested in semantic integration between
systems, be sure to read Chapter 14, "Maintaining Model Integrity".
I'd like to hear your comments on that chapter.

Eric

I've become quite interested in error messages recently. I'm inclined
to think that a good error message tells the user three things:
1) What the program tried to do.
2) What went wrong.
3) What the user might do about it.

It's the "what went wrong" that interests me most. Let's say that the
user is expected to have some sort of mental model of how the program
fits into her domain and how it works. That model will be different
from how the program actually works.

For example, a user of Internet Explorer thinks of bookmarks as names
for URLs that persist from session to session. The implementation
thinks of bookmarks as files that contain URLs. That's a problem if
you can persuade IE to try to create a bookmark called "RUP: Unit
Testing", because that was not a valid filename on DOS. The error
message is in terms of filenames, which I think is completely
bewildering to too many users. (For more on this bug, see this:
<http://www.visibleworkings.com/papers/ready-to-hand-bugs.pdf>.)

It seems that errors discovered deep in the bowels of the
implementation need to be translated back into the language of the
domain.

How can code be written to allow that? And can it be done without too
much pain? By that, I mean that any mechanism must, it seems to me,
require bookkeeping work of programmers - some executable statement
or declaration in the code that says, "See that bookmark name there?
Henceforth, it's to be considered also a filename." Pragmatically, if
the bookkeeping is too painful, programmers won't do it. Even if they
do, we'd like to avoid bookkeeping that makes the code harder to
understand and change.

I'd love to discuss this with people at OOPSLA next week or through
this list. (Eric said it's relevant.) I'm also on the hunt for
references, patterns, idioms, stories of success and failure. (I'm
familiar with aspects, though not with any example that works through
how AOP might be used for this problem, and also with some of the
literature on getting expert systems to explain their reasoning,
though that familiarity is out of date - so specific cites always
welcome.)

Thanks.

--
--

"Act always so as to increase the number of choices." -- Heinz von Foerster

--
Brian Marick, marick@...
www.testing.com - Software testing services and resources
www.testingcraft.com - Where software testers exchange techniques
www.visibleworkings.com - Adequate understanding of system internals

Message: 2
    Date: Fri, 11 Oct 2002 19:29:36 -0000
    From: "Eric Evans" <eric@...>
Subject: Re: Domain Driven Design BOF at OOPSLA

Ralph actually proposed doing two sessions. The first, on Monday
night, would naturally be mostly people who knew about the BOF before
hand, and might be a lot more familiar with the subject. The second,
on Wednesday night, would give people who just found out about it at
OOPSLA a chance to attend. (Maybe the people who attend the first
will tell others about it. Maybe the people from this group will
spread the word.) It would also be a fallback for those with a
conflict on Monday, although we would encourage you to come to the
first session.

So, what does this group think of having two sessions? Are those good
times for them? Do many of you plan to come?

[Mary Poppendieck] I have a conflict Monday night, will have to come to
the Wednesday night one.

Mary Poppendieck
www.poppendieck.com
952-934-7998

A BOF can't be officially scheduled until the beginning of the
conference. Then it is a first-come first-served signup. So instead
we'll have a target date and time, realizing it could change. We had
planned to run the choices by this group for input, and now is as
good a time as any.

Ralph actually proposed doing two sessions. The first, on Monday
night, would naturally be mostly people who knew about the BOF before
hand, and might be a lot more familiar with the subject. The second,
on Wednesday night, would give people who just found out about it at
OOPSLA a chance to attend. (Maybe the people who attend the first
will tell others about it. Maybe the people from this group will
spread the word.) It would also be a fallback for those with a
conflict on Monday, although we would encourage you to come to the
first session.

So, what does this group think of having two sessions? Are those good
times for them? Do many of you plan to come?

-Eric

--- In domaindrivendesign@y..., "Mary Poppendieck" <mary@p...> wrote:
> Ralph,
>
> When is this scheduled (or has it been yet)?
>
> Mary Poppendieck
>
> --- In domaindrivendesign@y..., "Ralph E. Johnson" <johnson@c...>
> wrote:
> > I am planning on running a BOF at OOPSLA on Eric's book on
> > Domain-Driven Design.  I'm thinking of the name "A book in three
> > hours".  I'm thinking of going through the book and discussing
> > the problem and solution of each pattern, but skipping everthing
> else.
> > Three hours might be ambitious; if we start at 7 then there is no
> > telling how long we might go.  But my goal would be to look at the
> > entire book, and I will moderate the discussion heavily so that
we
> > can actually finish that evening.
> >
> > Would you be interested in coming?  I've already talked to Eric
> > about it.  Any suggestions?
> >
> > -Ralph

Ralph,

When is this scheduled (or has it been yet)?

Mary Poppendieck

--- In domaindrivendesign@y..., "Ralph E. Johnson" <johnson@c...>
wrote:
> I am planning on running a BOF at OOPSLA on Eric's book on
> Domain-Driven Design.  I'm thinking of the name "A book in three
> hours".  I'm thinking of going through the book and discussing
> the problem and solution of each pattern, but skipping everthing
else.
> Three hours might be ambitious; if we start at 7 then there is no
> telling how long we might go.  But my goal would be to look at the
> entire book, and I will moderate the discussion heavily so that we
> can actually finish that evening.
>
> Would you be interested in coming?  I've already talked to Eric
> about it.  Any suggestions?
>
> -Ralph

You are probably right that it shouldn't be "AKA". Yet they are very
closely related. When most of us read the POSA book, we are thinking
about technical architecture, languages, and so forth. However, if
you take a look at the POSA discussion of Reflection, and think about
the context of domain design, you'll see what I mean. They didn't
even write it in a way that was specifically technical. Their
examples are technical, and the context of the book as a whole is,
too, but Reflection is more general than that.

What I may do is describe it as an application of Reflection to non-
technical domains. I do want to draw on POSA. The list of
consequences, and really most of the discussion there, is relevant
and well organized.

-Eric


--- In domaindrivendesign@y..., Joshua Kerievsky <jlk@i...> wrote:
> Eric,
>
> I wouldn't associate Knowledge Level with Reflection as you have.
As you
> know, Knowledge Level is that fine pattern from Martin's first book
while
> Reflection can mean many things to the reader.
>
> best regards
> jk
>
> I n d u s t r i a l  L o g i c , I n c .
> Joshua Kerievsky
> Founder, Extreme Programmer & Coach
> http://industriallogic.com
> 510-540-8336

Eric,

I wouldn't associate Knowledge Level with Reflection as you have.  As you
know, Knowledge Level is that fine pattern from Martin's first book while
Reflection can mean many things to the reader.

best regards
jk

I n d u s t r i a l  L o g i c , I n c .
Joshua Kerievsky
Founder, Extreme Programmer & Coach
http://industriallogic.com
510-540-8336

I am sure that there probably are some metrics that define a "small"
project.

I think it is relative and dependent on (1) the size of the team, (2)
experience of the team in the given domain and technology (3) the
typical scale of projects in the organization.

So, for example, if a typical project in a company X takes 10
engineers 6 months, then a "small" one would take the same team a
considerably shorter amount of time, or a smaller team the same
amount of time.

That's one way of looking at it.

Vlad

--- In domaindrivendesign@y..., Joel Jones <jones@c...> wrote:
> I like the description of the Smart UI anti-pattern.  However, I
> think a concrete example of what a "small" project is, would help.
> In particular, I have always had trouble getting across to my
> students what I mean when I say "small."  Their small is much
smaller
> than mine!  A system for writing a traffic ticket may constitute a
> small system, but one for writing a traffic crash report probably
is
> not.
>
> Joel Jones
> jones@c...
> http://cs.ua.edu/~jones

You make a good point. To actually define "small" would be beyond my
abilities, but I might be able to give a couple of brief examples. I
suppose that in general I'd agree that it falls somewhere between a
traffic ticket and a crash report, although it depends on what's
going on behind the scenes. I could imagine a crash report
application that just slammed data into a database. I could imagine a
traffic ticket app that looked for outstanding warrents and compared
the offender's record against policies and occasionally threw up a
red flag.

I'll consider adding such an example. If I don't, it will mostly be
to avoid scope creep on the book. It is interesting that people have
responded so well to the Smart UI section. Of course, the book is
specifically not about that. The only reason for including it is to
help mark the boundaries of applicability of domain-driven design and
to clarify the concept by contrasting it with something else. Of
course, it would do a better job of marking boundaries if I could
show what "small" is. But then I'd also have to talk in more detail
about team skill, I suppose.

-Eric

--- In domaindrivendesign@y..., Joel Jones <jones@c...> wrote:
> I like the description of the Smart UI anti-pattern.  However, I
> think a concrete example of what a "small" project is, would help.
> In particular, I have always had trouble getting across to my
> students what I mean when I say "small."  Their small is much
smaller
> than mine!  A system for writing a traffic ticket may constitute a
> small system, but one for writing a traffic crash report probably
is
> not.
>
> Joel Jones
> jones@c...
> http://cs.ua.edu/~jones

I think it is useful to distinguish the things we do for purely
technical reasons from those we do to express a domain model. In your
example, you want to test the type of a service providing class to
support pooling and so forth. There is no conceptual identity
confered on the object. Even the "equality" is not relevant in the
domain model, as it would be for a value object.

So, if such methods have to be attached to support the technical
framework, that's fine and normal. But they are not expressing the
model, and you want to keep that in mind. Nothing within the domain
layer should care about that method.

-Eric


--- In domaindrivendesign@y..., "Nabeel Mukhtar" <fazeel1@s...> wrote:
> Hi
> Alongside entities and value objects Eric also mentions services.
> However there is some confusion in my mind regarding the identity
of
> service objects. Is it correct to assume that all instances of a
> service class are equal, if they are stateless? I have seen service
> implementations to have this sort of test for equality.
>
> public class SomeService {
> ....
>
> public boolean equals(Object other) {
>     return (other instanceof SomeService)
>     // or other.getClass().equals(this.getClass());
> }
> }
>
> Certainly this is useful for stateless session bean implementations
> because the container pools the intances and reuses the objects for
> other invocations. Is it the general principle?
>
> Regards
> Nabeel Mukhtar

I like the description of the Smart UI anti-pattern.  However, I
think a concrete example of what a "small" project is, would help.
In particular, I have always had trouble getting across to my
students what I mean when I say "small."  Their small is much smaller
than mine!  A system for writing a traffic ticket may constitute a
small system, but one for writing a traffic crash report probably is
not.

Joel Jones
jones@...
http://cs.ua.edu/~jones

Ralph,

I'd be interested in attending - but I am only there on Monday and
Tuesday.

Chris

--- In domaindrivendesign@y..., "Ralph E. Johnson" <johnson@c...>
wrote:
> I am planning on running a BOF at OOPSLA on Eric's book on
> Domain-Driven Design.  I'm thinking of the name "A book in three
> hours".  I'm thinking of going through the book and discussing
> the problem and solution of each pattern, but skipping everthing
else.
> Three hours might be ambitious; if we start at 7 then there is no
> telling how long we might go.  But my goal would be to look at the
> entire book, and I will moderate the discussion heavily so that we
> can actually finish that evening.
>
> Would you be interested in coming?  I've already talked to Eric
> about it.  Any suggestions?
>
> -Ralph

If services are stateless then one is about the same
as another and it is fine to have all the services in
one class be equal to each other.  On the other hand,
if they are stateless then they probably don't take
much space and it might not be worth worrying about it.

-Ralph

Hi
Alongside entities and value objects Eric also mentions services.
However there is some confusion in my mind regarding the identity of
service objects. Is it correct to assume that all instances of a
service class are equal, if they are stateless? I have seen service
implementations to have this sort of test for equality.

public class SomeService {
....

public boolean equals(Object other) {
     return (other instanceof SomeService)
     // or other.getClass().equals(this.getClass());
}
}

Certainly this is useful for stateless session bean implementations
because the container pools the intances and reuses the objects for
other invocations. Is it the general principle?

Regards
Nabeel Mukhtar

I think it will be a very useful session. I will definitely be
interested in attending.

Also, the book appears to be more than just a collection of patterns.
There is a narrative that brings it together as a cohesive idea, and
I wonder if you could cover that to some extent as well.

Thanks,
Vlad





--- In domaindrivendesign@y..., "Ralph E. Johnson" <johnson@c...>
wrote:
> I am planning on running a BOF at OOPSLA on Eric's book on
> Domain-Driven Design.  I'm thinking of the name "A book in three
> hours".  I'm thinking of going through the book and discussing
> the problem and solution of each pattern, but skipping everthing
else.
> Three hours might be ambitious; if we start at 7 then there is no
> telling how long we might go.  But my goal would be to look at the
> entire book, and I will moderate the discussion heavily so that we
> can actually finish that evening.
>
> Would you be interested in coming?  I've already talked to Eric
> about it.  Any suggestions?
>
> -Ralph

I am planning on running a BOF at OOPSLA on Eric's book on
Domain-Driven Design.  I'm thinking of the name "A book in three
hours".  I'm thinking of going through the book and discussing
the problem and solution of each pattern, but skipping everthing else.
Three hours might be ambitious; if we start at 7 then there is no
telling how long we might go.  But my goal would be to look at the
entire book, and I will moderate the discussion heavily so that we
can actually finish that evening.

Would you be interested in coming?  I've already talked to Eric
about it.  Any suggestions?

-Ralph