Re: SV: SV: SV: SEAM - Is it better for some domains and not others

Yes, these are the two main problems with "properties".
- We implemented IsValid, IsValidForUpdate and IsValidForInsert etc, methods in each entity. A control is made before every save. So only valid entities are saved.
- These also check that a Save can not  Close a Case.
- Closing is done with another command in the UI not with Save.
- Each entity also implements its own Save method. So Save does not Close.
No validation done in a single property can ensure correctness, so each entity should be validated as a whole.

----- Original Message ----
From: Tomas Karlsson <tomas.lg.karlsson <at> telia.com>
To: domaindrivendesign <at> yahoogroups.com
Sent: Wednesday, April 30, 2008 6:02:42 PM
Subject: SV: SV: SV: [domaindrivendesign] SEAM - Is it better for some domains and not others

Things are getting worse. We are now looking at how one is working with an object in a graphical interface. Data is changed, possibly in many fields before "save". But we don't want to check business rules until data is saved. However, the result of business rule evaluations depend on the order.

 

Example 1: if a Case i custormer service is closed one cannot add more information to it. So 'add note and close' is valid while 'close and add note' is invalid. And if both are made in the UI before save, we are totally lost in the evaluation of business logic.

 

Example 2: assume an order has maximum of five order lines. In the UI, the user should be able to add more than five lines transiently. Validation should be made as 'save'. Not before that. (I still remember VB6 when one was not allowed to change line in the editor if the line had a syntax error...)

 

So we have to ensure business logic can be evaluated after multiple changes - but without forcing the user to specify an order. This will not be easy

 

So maybe we should try to look for aggregare invariants rather than business rules? But there will still be a problem in example 1.

 

/Tomas

Från: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] För Rickard Öberg
Skickat: den 29 april 2008 10:43
Till: domaindrivendesign <at> yahoogroups.com
Ämne: Re: SV: SV: [domaindrivendesign] SEAM - Is it better for some domains and not others

Tomas Karlsson wrote:
> However, if any Web framwork uses the same object, it will still use
> JavaBeans style and expect a public setName(...) . Maybe accessing the
> private metod using reflection (in Java). So the object will still
> appear as 'subject for operation' in the DDD-style domain and 'container
> for attributes' in the Web layer.

So the object is "attacked" from two fronts at the same time: below from
the database, and above from the web/UI layer. And in the middle we want
to hide it all behind an encapsulated API so that that the
implementations are just that. It's a tricky problem, no doubt. Randy,
heeeelp!

One way to look at it is that the properties are always hidden from an
API point of view, but always available from an SPI point of view, or
"reflection point of view", for both UI's and data mappers. The question
is how to ensure that business rules are enforced properly, I guess.

The question is what compromises we have to make, and still get what we
want. I don't know the answer to that one

/Rickard

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. __._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

Re: SV: SV: SEAM - Is it better for some domains and not others

Breaking the dependency between entities and DAOs

I am implementing an application using DDD principles. I am using
Hibernate for persistence. I would like to keep the domain model
independent of my persistence mechanism. So the first thought was to
retrieve relevant domain objects in the service layer and then start
calling methods on these objects to implement the application's
functionality. However this is proving to be very tough and I would
like to get any pointers on how others have tackled this issue. Here's
a specific example (it is in the trading domain):

I have an entity called Security. A Security maintains a history of
TargetPrices. Thus we have a one-to-many relationship between Security
and TargetPrice. There is an external algorithm that runs
periodically, looks at a whole lot of market parameters and determines
the next target price for each security. It then calls
Security.setTargetPrice() for each security. The security object needs
to do the following:

find the last target price from the history
if (new target price != last target price) {
    create a new target price record
    inform traders that the target price has changed
}

Now how can a security do this? I certainly don't want to pull in all
the TargetPrices before calling the method - that's thousands of
records and is very inefficient. I also do not want to call a DAO from
the Security object because that creates a circular dependency - DAOs
certainly depend on domain objects and now the domain objects suddenly
depend on a DAOs! How have you tackled this issue in your projects?

P.S. Of course, I could rely on Hibernate's lazy loading mechanism to
pull in all TargetPrices automatically, search through them and add
one if necessary, but that's highly inefficient.

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

Re: SV: SV: SEAM - Is it better for some domains and not others

Re: SV: How do you introduce DDD to domain experts?

I agree with you.  Most of what you've said reflects my thoughts the 
past few days too.  I think the critical thing to get across to the 
domain experts is if we (the developers) say something they don't 
understand, then we need to rephrase and put it in the language the 
domain experts speak or we're misunderstanding something and need to be 
put right.

Similarly, as developers, we need to pay attention to what the domain 
experts are saying and if they say something we don't understand we need 
to have them pause and give us more detail so we have a more solid 
understanding.  I think the important thing is to get to a point where 
we're all speaking the same language.

Thinking about it in terms of scenarios is interesting.  Doing that will 
definitely help my domain experts see how the domain model ties into 
what they are actually trying to accomplish.  But if you build the model 
from scenarios that the expert gives you rather than building the model 
with the expert and going over scenarios with them, that starts to sound 
more like Feature Driven Development and not Domain Driven Development.

I don't know, looking at it it almost seems like a "6 of one and 
half-a-dozen of the other" kind of comparison.  The most important thing 
is always in talking to your users, the experts, and working to find a 
model that accomplishes their goals.

Rich

Tomas Karlsson wrote:
>
> I don't think you should present DDD as a methodology or tool or 
> anything to the domain experts. It is your (and my) job to ask the 
> right questions to the domain experts to figure out the domian model. 
> That's what we are paid for. If you should talk about any part of DDD 
> with the domain experts, talk about the ubiquitous language. Tell them 
> that IT and business need to share language. They will understand! 
> Talk about the sematics of language (and not syntax in XML file or 
> data models). They will understand!
>  
> I have found it useful to compare to natural language. Especially 
> powerful is to find situations of misunderstanding from the lunch 
> table or the coffee room. So when you want to know exactly what a 
> 'customer' is, you can refer to the lunch when one person from UK and 
> on from the US misundestood each other when talking about 'football'. 
> Data convertion in software integration can be compared to translation 
> of a novel. Etc.
>  
> Last week I found a nice example of a workaroud (commonly used when a 
> fiels is missing in an application). Exactly what is the connection 
> between a 'fasten seat belt sign' and a laptop? I don't know, but I 
> have learnet that I am not allowed to start my laptop until the fasten 
> seatbelt sign is switched off. Simply because the 'laptop sign' is 
> missing on commersion airliners 
>  
> A few more thing I have found useful:
> - Use object diagrams (rather then class diagrams) and scenarios 
> (rather than use cases). That make things more real to the domain 
> experts. Drawing two boxes is better than drawing one box with that 
> UML '*' followed by a discussion about cardinalities in UML
> - Spend some time on finding real buisness data - the business people 
> will like it for two reasons: They will understand what you are 
> talking about and they find that you are really care about the business
> - Ask a lot of questiont to confirm you are right (or wrong). But ask 
> on real scenarios and not 'what does the model look like?' in general
> - Be prepared to meet people with a lower level of abstract thinking 
> than a normal programmer 
>  
> As one of 'my' domain experts said after a modelling session: I don't 
> care about what the information model (part of the complete domain 
> model) looks like. I just want to do this and that and... And then he 
> gave us a number of key scenarios in the domain! And if the business 
> or the project (!) come up with a scenario not supported by the domain 
> model, then you have to refactor.
>  
> /Tomas
>
> ------------------------------------------------------------------------
> *Från:* domaindrivendesign <at> yahoogroups.com 
> [mailto:domaindrivendesign <at> yahoogroups.com] *För *Richard Wallace
> *Skickat:* den 30 april 2008 17:57
> *Till:* domaindrivendesign <at> yahoogroups.com
> *Ämne:* [domaindrivendesign] How do you introduce DDD to domain experts?
>
> Hello,
>
> I'm starting a new project and am planning to use DDD. I've read Eric
> Evans book and found that many of the concepts are things that I've used
> in the past, but the idea of the ubiquitous language and the way in
> which you talk to the domain experts is something that will be somewhat
> new to me. In the past I have used XP methods and come up with stories
> which we use for planning, etc. with varying success. I think one of
> the missing elements in the past that led to some failures and
> misunderstandings was the ubiquitous language. I'm curious how people
> go about introducing new domain experts to the concepts of DDD,
> specifically things like the ubiquitous language and it's correspondence
> with the model and code.
>
> The situation I'm entering is one where the domain experts are
> completely non-technical users who have never done anything like this
> before. Do you think any introduction is necessary? Any ideas on how I
> can help them understand what I need from them in order to be able to
> properly meet their needs?
>
> Any input is appreciated,
> Rich
>
>  

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

Real DDD Case Studies/Companies

What are some real companies or case studies that use DDD?  Anyone
know? I would love to see a list of or read about successful
utilizations of DDD to any degree.

Eric's entry about "Barriers to adoption / keys to acceptance"
(at:http://tech.groups.yahoo.com/group/domaindrivendesign/message/774)
intrigues me because I really like DDD, but, I am wondering if any
real, salary-paying companies out there truly buy into it--at least at
this juncture.  

The items that Scott put out there in response to Eric's entry
(at:http://tech.groups.yahoo.com/group/domaindrivendesign/message/776)
are a lot of what I've seen in my experience.  I am currently
struggling with having to work in an environment that does not
subscribe to DDD in any substantial shape or form.  It makes me wonder
if I need to put the brakes on DDD for a while???? Nonetheless, I am
sure that it is just the companies I've worked with thus far.  

Basically, I would like to know what the state of DDD in the real
world is.

--Monico

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

Re: SV: How do you introduce DDD to domain experts?

Those scenarios are important. They anchor everyone, and we need that 
anchor when working on abstract models, or we'll just float off into 
clouds of abstractions. But you raise an important risk:
> But if you build the model
> from scenarios that the expert gives you rather than building the model
> with the expert and going over scenarios with them, that starts to sound
> more like Feature Driven Development and not Domain Driven Development.
The difference is that the cycle emphasizes constant conceptual 
consolidation. We are looking for a model that parsimoniously resolves a 
range of scenarios.

One other thing I'd throw into this discussion. It is important to spend 
the time with the experts in a way that reinforces their interest in 
being there. I've been in too many analysis discussions where the team 
has finally nailed down a few hours of an important business person, and 
they spend it grilling him/her on whether this field could be left 
blank, or how many characters would we need in this field. Ask important 
questions. Why? and then why? and why that? And quickly (within two 
weeks) do a crude prototype or something to test your model and show 
them what the impact of their involvement is.

Eric

Richard Wallace wrote:
>
> I agree with you. Most of what you've said reflects my thoughts the
> past few days too. I think the critical thing to get across to the
> domain experts is if we (the developers) say something they don't
> understand, then we need to rephrase and put it in the language the
> domain experts speak or we're misunderstanding something and need to be
> put right.
>
> Similarly, as developers, we need to pay attention to what the domain
> experts are saying and if they say something we don't understand we need
> to have them pause and give us more detail so we have a more solid
> understanding. I think the important thing is to get to a point where
> we're all speaking the same language.
>
> Thinking about it in terms of scenarios is interesting. Doing that will
> definitely help my domain experts see how the domain model ties into
> what they are actually trying to accomplish. But if you build the model
> from scenarios that the expert gives you rather than building the model
> with the expert and going over scenarios with them, that starts to sound
> more like Feature Driven Development and not Domain Driven Development.
>
> I don't know, looking at it it almost seems like a "6 of one and
> half-a-dozen of the other" kind of comparison. The most important thing
> is always in talking to your users, the experts, and working to find a
> model that accomplishes their goals.
>
> Rich
>
> Tomas Karlsson wrote:
> >
> > I don't think you should present DDD as a methodology or tool or
> > anything to the domain experts. It is your (and my) job to ask the
> > right questions to the domain experts to figure out the domian model.
> > That's what we are paid for. If you should talk about any part of DDD
> > with the domain experts, talk about the ubiquitous language. Tell them
> > that IT and business need to share language. They will understand!
> > Talk about the sematics of language (and not syntax in XML file or
> > data models). They will understand!
> >
> > I have found it useful to compare to natural language. Especially
> > powerful is to find situations of misunderstanding from the lunch
> > table or the coffee room. So when you want to know exactly what a
> > 'customer' is, you can refer to the lunch when one person from UK and
> > on from the US misundestood each other when talking about 'football'.
> > Data convertion in software integration can be compared to translation
> > of a novel. Etc.
> >
> > Last week I found a nice example of a workaroud (commonly used when a
> > fiels is missing in an application). Exactly what is the connection
> > between a 'fasten seat belt sign' and a laptop? I don't know, but I
> > have learnet that I am not allowed to start my laptop until the fasten
> > seatbelt sign is switched off. Simply because the 'laptop sign' is
> > missing on commersion airliners 
> >
> > A few more thing I have found useful:
> > - Use object diagrams (rather then class diagrams) and scenarios
> > (rather than use cases). That make things more real to the domain
> > experts. Drawing two boxes is better than drawing one box with that
> > UML '*' followed by a discussion about cardinalities in UML
> > - Spend some time on finding real buisness data - the business people
> > will like it for two reasons: They will understand what you are
> > talking about and they find that you are really care about the business
> > - Ask a lot of questiont to confirm you are right (or wrong). But ask
> > on real scenarios and not 'what does the model look like?' in general
> > - Be prepared to meet people with a lower level of abstract thinking
> > than a normal programmer 
> >
> > As one of 'my' domain experts said after a modelling session: I don't
> > care about what the information model (part of the complete domain
> > model) looks like. I just want to do this and that and... And then he
> > gave us a number of key scenarios in the domain! And if the business
> > or the project (!) come up with a scenario not supported by the domain
> > model, then you have to refactor.
> >
> > /Tomas
> >
> > ----------------------------------------------------------
> > *Från:* domaindrivendesign <at> yahoogroups.com 
> <mailto:domaindrivendesign%40yahoogroups.com>
> > [mailto:domaindrivendesign <at> yahoogroups.com 
> <mailto:domaindrivendesign%40yahoogroups.com>] *För *Richard Wallace
> > *Skickat:* den 30 april 2008 17:57
> > *Till:* domaindrivendesign <at> yahoogroups.com 
> <mailto:domaindrivendesign%40yahoogroups.com>
> > *Ämne:* [domaindrivendesign] How do you introduce DDD to domain experts?
> >
> > Hello,
> >
> > I'm starting a new project and am planning to use DDD. I've read Eric
> > Evans book and found that many of the concepts are things that I've used
> > in the past, but the idea of the ubiquitous language and the way in
> > which you talk to the domain experts is something that will be somewhat
> > new to me. In the past I have used XP methods and come up with stories
> > which we use for planning, etc. with varying success. I think one of
> > the missing elements in the past that led to some failures and
> > misunderstandings was the ubiquitous language. I'm curious how people
> > go about introducing new domain experts to the concepts of DDD,
> > specifically things like the ubiquitous language and it's correspondence
> > with the model and code.
> >
> > The situation I'm entering is one where the domain experts are
> > completely non-technical users who have never done anything like this
> > before. Do you think any introduction is necessary? Any ideas on how I
> > can help them understand what I need from them in order to be able to
> > properly meet their needs?
> >
> > Any input is appreciated,
> > Rich
> >
> >
>
>  

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

Re: Breaking the dependency between entities and DAOs

Re: Barriers to adoption / keys to acceptance

Scott, your post PERFECTLY represents everything I feel all this time.
In every projects I have worked on, unfortunately no one put enough
appreciation to design. 
Leads never care about good design, which is very reasonable
considering he has to care more about survival in the business, ie
letting all developers do whatever they want as long as the job is
done ASAP, and all identified bugs are fixed. If the current way works
well (in business term), then why care about design? 
Peer reviews tend to be intendted to spot potential bug or coding
convention (like naming, loging, bracket stuffs). But every design
talk would be quickly dumped as an unproductive discussion. 
If the leads don't care, it's almost impossible to even talk about
design with the team. Any attempt to discuss TDD, DDD, and stuffs will
just turn yourself into a weird geek talking non-sense academic
theory, listening to whom will not do you any practical benefit.
Problem is, people who can get the job done the quickest way possible,
is much more higly valued both from business and technical point of
view. The most horrible part, the defect fixer (support team) is
separate team from the developer team. So they, the sloppy developers,
do not have to care about paying for any of their sins. All they care
is to finish their job in quickest way possible using mean necessary,
committing all the sins you can name. 
Probably like u said, I just have bad luck as well. But my experience
has always prooven that all fancy design and technique, including DDD,
can't work in the pressure of real world business. In most places,
definition of bad developers has always been those who can't put
priority onto making things happen ASAP, over wasting time on keeping
design and practice, or those caring for fixing things that are not
exactly broken.
Unlike TDD, DDD IMO doesn't slow down development process, if not even
makes faster in some cases. But the learning curve does need time,
something the team never has enough.

--- In domaindrivendesign <at> yahoogroups.com, "Scott Hurlbert"
<scott@...> wrote:
>
> Eric,
> 
> Very interesting questions.  What follows are just my opinion, based
on my
> unique set of experiences.
> 
> Lead developers think it's quicker to hack
>   Perhaps I've just had bad luck or chosen poorly, but every lead I've
> worked with has thought it was too slow to do team oriented design once
> coding had started.
> 
>   I've work with a couple that would "humor" design and analysis
before team
> coding began but from that point forward, and on all subsequent
releases, it
> was hack-and-hope.
> 
>   What's most amazing was in every case these guys were pretty decent
> coders.
> 
>   Design is relegated to initial meetings, before any big changes,
where the
> changes are explained and some design is talked about.
> Great fear of changing working code
>   Redesign does not happen because the code is "working" or "in
production."
> When a simplifying change is suggested, the response is inevitably, "No,
> don't do that it'll cause too many code changes - we'll have to do full
> regression testing and that's too dangerous for this release," or
"No, that
> change will effect too much of the code, it's too dangerous."
> 
>   Even if you point out that the reason why the change touches so
much code
> is that it simplifies areas of great confusion the fear is too
prevalent.
> Management values working code over code that works well
>   This relates to the fear of changing working code above, but goes
a bit
> deeper.   When asked to make a change our team is always asked to give a
> time estimate.  This method of estimation often makes it impossible
to take
> advantage of deeper insights to the model.   If you get insights, the
> process of going to the lead, convincing him, getting him to go to the
> project manager, convincing him, going to the project sponsor,
convincing
> them, and getting them to go to their manager (whew) is just too much.
> 
>   Also, in our organization, this path requires cutting across political
> boundaries as well as project boundaries, making such requests
inherently
> negotiation rich.  You are as likely to be asked to give something
up as you
> are to have several more requirements thrown at you.  And anything
that is
> seen as a delay - almost without exception - is impossible to get
approved.
> Ironically, time and time again I have seen this cause delays due to
bugs,
> testing, and requirement changes that could not be easily accommodated
> because of a lack of a better model.
> Inadequate testing makes medium/large refactoring or restructuring
> impossible
>   Our organization bargains downward - meaning that once the
developers set
> a schedule, changes to scope and requirements get taken out of
development
> time.   This causes the developers to make many changes at the last
minute,
> which is error prone.
> 
>   If development is late, the time is taken out of testing - rarely
are the
> deadlines extended - regardless of the reasons for the delay.  This
often
> causes bugs to be found late in the process and then rework to occur
after
> much of the testing is done.  This results in even fewer bugs being
found.
> 
>   Also, viewing testing as a separate process, which happens after
> development makes big changes seem more risky.
> 
>   Because of this needless pressure late in the process, trying to get
> people to slow down long enough to rework the model is very hard.
> Requirements process and timeline negotiations kill the
collaboration with
> domain experts
>   The political process where I work makes going to the domain
experts very
> risky.  You get your chance to talk to them all you want until you
set the
> schedule.   After that, you may discover changes that would affect the
> timeline and that's taboo.   I've actually had the lead respond to
one of my
> suggestions before a meeting with, "Oh wow, that's a good idea - ok,
don't
> say anything in this meeting because that'll be too much work.  If you
> mention it I know they'll want us to do that."
> DDD requires a more homogeneous team
>   The teams I've been around followed the anti-pattern of making
everyone an
> expert in some area of the code, making large domain changes nearly
> impossible.
> 
>   Some of this is for historical reasons and some is because people are
> assumed to have certain skills only - "He's good at GUI."  "He's a
DB guy."
> etc.
> We can do that in the next release, when we'll have more time
>   For some reason, probably human nature, it seems that everyone thinks
> we'll do better next time.  Changes to the domain that seem really
smart to
> make, are too risky now, but "once we have this release out, we'll
take a
> look at that."
> If your current design is procedural (even in java or .net) model
changes
> are difficult and wide spread
>   Because of everything mentioned above, a lot of the code gets
written in a
> procedural manner and, as you pointed out in your book, this happens
even
> when working with an oop language.
> 
>   Since procedural code poorly represents most domains, supporting a
domain
> model (as compared to a set of procedures) is naturally supporting a
lot of
> changes.   (And in your best Mr. Mackey voice:  "Changes are bad,
m'kay?.")
> So those are some basic reasons.  What all this means in practical
terms is
> that my organization is not too bad at doing one release.  But in
EVERY case
> that I've seen the second release is a disaster and the third is
cancelled
> or scaled back to bug fixes and enhancements of the previous releases.
> After that, things start to get killed or phased out.  However, it's not
> usually that clear cut.   Years are spent talking about a fix, but
> inevitably someone suggest a rewrite and that is summarily killed.
> 
> In one case, our project manager said he wanted a small (30k LOC)
project
> fixed because it had a lot of bugs and suffered from frequent
crashes.   I
> studied the app for a while and told him it was not possible to fix the
> current program.  Design flaws in the code, combined with missing
keys in
> the database, made it impossible to fix.   (In this case the
original coder
> had not understood event driven apps, especially under windows, and
he had
> coded dozens of screens that had event code which was contradictory
- one
> screen would move record pointers and change recordset data being
used by
> another screen and so on - it was a real mess.)
> 
> I was also able to show that the bugs they thought had been
introduced in a
> previous patch had indeed existed since the event code had been
written two
> year earlier.
> 
> I told the managers that all this needed to be rewritten and
suggested that
> it would take around 9 months.    They threw a fit and offshored the
> project.  At the time, there was myself and another guy working on the
> project.  When they offshored it they put 5 guys on the project (because
> they are cheaper I guess) and told them to do the fixes that I said
required
> a rewrite.
> 
> That was 16 months ago and they have yet to ship a line of code
because they
> cannot get the bugs to go away.
> 
> Ok, I'm done venting.  Thanks for listening.
> 
> Scott
> 
> PS - Eric, did you get a chance to look at the message below?  I may
have
> missed your response:
> 
> I'm just really jazzed about the book, and I've been trying to implement
> some of what I've learned. I was wondering if I could ask you a
questions?
> (At this point all assume you say yes, if the answer is no, please
ignore
> all below 
> 
> I'm working on a WebSphere app that has the following tiers:
> 
> WEBAPP WEBSERVER DATABASE
> 
> HTML->JSP->STRUTS------>FACADE->DataAccessObjects------->ORACLEDB
> 
> The deployment of the left side is separate from the middle and of
course
> the right side is another server with Oracle installed.
> 
> When this project got started we spent the first couple of months
modeling.
> We hadn't officially received approval to build anything, but we had the
> team so we said, "let's take what we do know and forge ahead with a
> preliminary model." In retrospect, what happened next was
predictable, but
> it caught me by surprise.
> 
> We got approval to build and there was ONE PASS where the ideas were
taken
> out of the UML model and made into DTOs, DAOs, VALUE_OBJECTS, and the
> FACADE. However, at this point the "model" was jettisoned, never to
be used
> again.
> 
> Of course the problem with this was that we had left behind much of
the know
> ledge about dynamic behavior and we had not built a DOMAIN DRIVEN
system. I
> would call it more of a DOMAIN SUGGESTED system (ha ha).
> 
> This has caused us many problems since. However, we've shipped the
product
> and the team has shrunk from 10 to 3 and we are now implementing
subsequent
> phases of the app. The problem is that without a DOMAIN DRIVEN
system, much
> of the domain logic ended up in TAGLIBS or in the STRUTS actions.
Getting a
> cohesive picture is very hard. Reuse is possible but a challenge -
TAGLIBS
> are of course reusable if they process generically enough, but the
struts
> actions tend to be very specific.
> 
> As I go back now and work on bits of it, I'm able to improve them
greatly
> using many of the ideas suggested in he book.
> 
> However, because of this tiering I'm unsure of where to put the domain
> model. I would think it would be very difficult to split it across the
> WEBAPP and the WEBSERVER. My initial thought was that it would go on one
> side or the other. Since the WEBAPP tends to be more "free wheeling" I
> started working on one of the subsystems and put a domain driven
model of
> the subsystem in place and it seemed to be a big help.
> 
> Still, when I asked Sam to stop by and do a friendship code review, he
> suggested that the domain model belongs on the webserver side of the
wire.
> 
> In our case the FACADE is a stateless session bean. Calls across the
wire
> here are many times slower (still fast though) than calls within the
webapp
> or the webserver themselves.
> 
> Both Sam and I had thought we had read some suggestions on locating the
> model in the book and we each grabbed our copies and tried to site
to the
> other the sections that proved our stand. We quickly realized that there
> aren't any clear architectural suggestions about this in the book.
> 
> I would think that anyone building a webapp would run into this.
With .NET
> it would be the ASP.NET server vs. .NET itself but the division is still
> there.
> 
> Any think you have to say on this would be great.
> 
> I'm currently going back and reading through the minutes of the SVP
Group
> notes, but have not seen this issue addressed.
> 
> Thanks a bunch, Scott
> 
> 
>   -----Original Message-----
>   From: Eric Evans [mailto:eric@...]
>   Sent: Friday, March 26, 2004 5:08 PM
>   To: domaindrivendesign <at> yahoogroups.com
>   Subject: [domaindrivendesign] Barriers to adoption / keys to
acceptance
> 
> 
>   Here's a non-technical question I'd like to hear people's thoughts
about.
>   What keeps the various aspects of domain-driven design from being
adopted
> in
>   an organization? What helps it spread? What arguments have proven
> persuasive
>   (in either direction)?
> 
>   For those whose organizations do DDD in some form, especially
where teams
>   operate this way, how did it get started? Has it spread within the
>   organization? What are the limits to its spread.
> 
>   Or, for those in places where it isn't used, what do you see as the
>   obstacles to its adoption? Is it resistance among developers?
Managers?
>   Architects? Is there a lack of awareness or knowledge about it, or
>   skepticism about its value?
> 
>   Eric
> 
> 
> 
>         Yahoo! Groups Sponsor
>               ADVERTISEMENT
> 
> 
> 
> 
> 
>
----------------------------------------------------------------------------
> --
>   Yahoo! Groups Links
> 
>     a.. To visit your group on the web, go to:
>     http://groups.yahoo.com/group/domaindrivendesign/
> 
>     b.. To unsubscribe from this group, send an email to:
>     domaindrivendesign-unsubscribe <at> yahoogroups.com
> 
>     c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>

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

Re: Re: Barriers to adoption / keys to acceptance

This sounds like a very dysfunctional organization ... I would doubt
that they would ever get themselves out of such a state no matter what
you do unless they completely clean house.

The law of two feet always applies.

Not everywhere is like that.

Greg

On Thu, May 1, 2008 at 7:15 PM, hendrypa <hendrymail <at> gmail.com> wrote:
>
>
>
>
>
>
> Scott, your post PERFECTLY represents everything I feel all this time.
>  In every projects I have worked on, unfortunately no one put enough
>  appreciation to design.
>  Leads never care about good design, which is very reasonable
>  considering he has to care more about survival in the business, ie
>  letting all developers do whatever they want as long as the job is
>  done ASAP, and all identified bugs are fixed. If the current way works
>  well (in business term), then why care about design?
>  Peer reviews tend to be intendted to spot potential bug or coding
>  convention (like naming, loging, bracket stuffs). But every design
>  talk would be quickly dumped as an unproductive discussion.
>  If the leads don't care, it's almost impossible to even talk about
>  design with the team. Any attempt to discuss TDD, DDD, and stuffs will
>  just turn yourself into a weird geek talking non-sense academic
>  theory, listening to whom will not do you any practical benefit.
>  Problem is, people who can get the job done the quickest way possible,
>  is much more higly valued both from business and technical point of
>  view. The most horrible part, the defect fixer (support team) is
>  separate team from the developer team. So they, the sloppy developers,
>  do not have to care about paying for any of their sins. All they care
>  is to finish their job in quickest way possible using mean necessary,
>  committing all the sins you can name.
>  Probably like u said, I just have bad luck as well. But my experience
>  has always prooven that all fancy design and technique, including DDD,
>  can't work in the pressure of real world business. In most places,
>  definition of bad developers has always been those who can't put
>  priority onto making things happen ASAP, over wasting time on keeping
>  design and practice, or those caring for fixing things that are not
>  exactly broken.
>  Unlike TDD, DDD IMO doesn't slow down development process, if not even
>  makes faster in some cases. But the learning curve does need time,
>  something the team never has enough.
>
>  --- In domaindrivendesign <at> yahoogroups.com, "Scott Hurlbert"
>  <scott@...> wrote:
>  >
>  > Eric,
>  >
>  > Very interesting questions. What follows are just my opinion, based
>  on my
>  > unique set of experiences.
>  >
>  > Lead developers think it's quicker to hack
>  > Perhaps I've just had bad luck or chosen poorly, but every lead I've
>  > worked with has thought it was too slow to do team oriented design once
>  > coding had started.
>  >
>  > I've work with a couple that would "humor" design and analysis
>  before team
>  > coding began but from that point forward, and on all subsequent
>  releases, it
>  > was hack-and-hope.
>  >
>  > What's most amazing was in every case these guys were pretty decent
>  > coders.
>  >
>  > Design is relegated to initial meetings, before any big changes,
>  where the
>  > changes are explained and some design is talked about.
>  > Great fear of changing working code
>  > Redesign does not happen because the code is "working" or "in
>  production."
>  > When a simplifying change is suggested, the response is inevitably, "No,
>  > don't do that it'll cause too many code changes - we'll have to do full
>  > regression testing and that's too dangerous for this release," or
>  "No, that
>  > change will effect too much of the code, it's too dangerous."
>  >
>  > Even if you point out that the reason why the change touches so
>  much code
>  > is that it simplifies areas of great confusion the fear is too
>  prevalent.
>  > Management values working code over code that works well
>  > This relates to the fear of changing working code above, but goes
>  a bit
>  > deeper. When asked to make a change our team is always asked to give a
>  > time estimate. This method of estimation often makes it impossible
>  to take
>  > advantage of deeper insights to the model. If you get insights, the
>  > process of going to the lead, convincing him, getting him to go to the
>  > project manager, convincing him, going to the project sponsor,
>  convincing
>  > them, and getting them to go to their manager (whew) is just too much.
>  >
>  > Also, in our organization, this path requires cutting across political
>  > boundaries as well as project boundaries, making such requests
>  inherently
>  > negotiation rich. You are as likely to be asked to give something
>  up as you
>  > are to have several more requirements thrown at you. And anything
>  that is
>  > seen as a delay - almost without exception - is impossible to get
>  approved.
>  > Ironically, time and time again I have seen this cause delays due to
>  bugs,
>  > testing, and requirement changes that could not be easily accommodated
>  > because of a lack of a better model.
>  > Inadequate testing makes medium/large refactoring or restructuring
>  > impossible
>  > Our organization bargains downward - meaning that once the
>  developers set
>  > a schedule, changes to scope and requirements get taken out of
>  development
>  > time. This causes the developers to make many changes at the last
>  minute,
>  > which is error prone.
>  >
>  > If development is late, the time is taken out of testing - rarely
>  are the
>  > deadlines extended - regardless of the reasons for the delay. This
>  often
>  > causes bugs to be found late in the process and then rework to occur
>  after
>  > much of the testing is done. This results in even fewer bugs being
>  found.
>  >
>  > Also, viewing testing as a separate process, which happens after
>  > development makes big changes seem more risky.
>  >
>  > Because of this needless pressure late in the process, trying to get
>  > people to slow down long enough to rework the model is very hard.
>  > Requirements process and timeline negotiations kill the
>  collaboration with
>  > domain experts
>  > The political process where I work makes going to the domain
>  experts very
>  > risky. You get your chance to talk to them all you want until you
>  set the
>  > schedule. After that, you may discover changes that would affect the
>  > timeline and that's taboo. I've actually had the lead respond to
>  one of my
>  > suggestions before a meeting with, "Oh wow, that's a good idea - ok,
>  don't
>  > say anything in this meeting because that'll be too much work. If you
>  > mention it I know they'll want us to do that."
>  > DDD requires a more homogeneous team
>  > The teams I've been around followed the anti-pattern of making
>  everyone an
>  > expert in some area of the code, making large domain changes nearly
>  > impossible.
>  >
>  > Some of this is for historical reasons and some is because people are
>  > assumed to have certain skills only - "He's good at GUI." "He's a
>  DB guy."
>  > etc.
>  > We can do that in the next release, when we'll have more time
>  > For some reason, probably human nature, it seems that everyone thinks
>  > we'll do better next time. Changes to the domain that seem really
>  smart to
>  > make, are too risky now, but "once we have this release out, we'll
>  take a
>  > look at that."
>  > If your current design is procedural (even in java or .net) model
>  changes
>  > are difficult and wide spread
>  > Because of everything mentioned above, a lot of the code gets
>  written in a
>  > procedural manner and, as you pointed out in your book, this happens
>  even
>  > when working with an oop language.
>  >
>  > Since procedural code poorly represents most domains, supporting a
>  domain
>  > model (as compared to a set of procedures) is naturally supporting a
>  lot of
>  > changes. (And in your best Mr. Mackey voice: "Changes are bad,
>  m'kay?.")
>  > So those are some basic reasons. What all this means in practical
>  terms is
>  > that my organization is not too bad at doing one release. But in
>  EVERY case
>  > that I've seen the second release is a disaster and the third is
>  cancelled
>  > or scaled back to bug fixes and enhancements of the previous releases.
>  > After that, things start to get killed or phased out. However, it's not
>  > usually that clear cut. Years are spent talking about a fix, but
>  > inevitably someone suggest a rewrite and that is summarily killed.
>  >
>  > In one case, our project manager said he wanted a small (30k LOC)
>  project
>  > fixed because it had a lot of bugs and suffered from frequent
>  crashes. I
>  > studied the app for a while and told him it was not possible to fix the
>  > current program. Design flaws in the code, combined with missing
>  keys in
>  > the database, made it impossible to fix. (In this case the
>  original coder
>  > had not understood event driven apps, especially under windows, and
>  he had
>  > coded dozens of screens that had event code which was contradictory
>  - one
>  > screen would move record pointers and change recordset data being
>  used by
>  > another screen and so on - it was a real mess.)
>  >
>  > I was also able to show that the bugs they thought had been
>  introduced in a
>  > previous patch had indeed existed since the event code had been
>  written two
>  > year earlier.
>  >
>  > I told the managers that all this needed to be rewritten and
>  suggested that
>  > it would take around 9 months. They threw a fit and offshored the
>  > project. At the time, there was myself and another guy working on the
>  > project. When they offshored it they put 5 guys on the project (because
>  > they are cheaper I guess) and told them to do the fixes that I said
>  required
>  > a rewrite.
>  >
>  > That was 16 months ago and they have yet to ship a line of code
>  because they
>  > cannot get the bugs to go away.
>  >
>  > Ok, I'm done venting. Thanks for listening.
>  >
>  > Scott
>  >
>  > PS - Eric, did you get a chance to look at the message below? I may
>  have
>  > missed your response:
>  >
>  > I'm just really jazzed about the book, and I've been trying to implement
>  > some of what I've learned. I was wondering if I could ask you a
>  questions?
>  > (At this point all assume you say yes, if the answer is no, please
>  ignore
>  > all below 
>  >
>  > I'm working on a WebSphere app that has the following tiers:
>  >
>  > WEBAPP WEBSERVER DATABASE
>  >
>  > HTML->JSP->STRUTS------>FACADE->DataAccessObjects------->ORACLEDB
>  >
>  > The deployment of the left side is separate from the middle and of
>  course
>  > the right side is another server with Oracle installed.
>  >
>  > When this project got started we spent the first couple of months
>  modeling.
>  > We hadn't officially received approval to build anything, but we had the
>  > team so we said, "let's take what we do know and forge ahead with a
>  > preliminary model." In retrospect, what happened next was
>  predictable, but
>  > it caught me by surprise.
>  >
>  > We got approval to build and there was ONE PASS where the ideas were
>  taken
>  > out of the UML model and made into DTOs, DAOs, VALUE_OBJECTS, and the
>  > FACADE. However, at this point the "model" was jettisoned, never to
>  be used
>  > again.
>  >
>  > Of course the problem with this was that we had left behind much of
>  the know
>  > ledge about dynamic behavior and we had not built a DOMAIN DRIVEN
>  system. I
>  > would call it more of a DOMAIN SUGGESTED system (ha ha).
>  >
>  > This has caused us many problems since. However, we've shipped the
>  product
>  > and the team has shrunk from 10 to 3 and we are now implementing
>  subsequent
>  > phases of the app. The problem is that without a DOMAIN DRIVEN
>  system, much
>  > of the domain logic ended up in TAGLIBS or in the STRUTS actions.
>  Getting a
>  > cohesive picture is very hard. Reuse is possible but a challenge -
>  TAGLIBS
>  > are of course reusable if they process generically enough, but the
>  struts
>  > actions tend to be very specific.
>  >
>  > As I go back now and work on bits of it, I'm able to improve them
>  greatly
>  > using many of the ideas suggested in he book.
>  >
>  > However, because of this tiering I'm unsure of where to put the domain
>  > model. I would think it would be very difficult to split it across the
>  > WEBAPP and the WEBSERVER. My initial thought was that it would go on one
>  > side or the other. Since the WEBAPP tends to be more "free wheeling" I
>  > started working on one of the subsystems and put a domain driven
>  model of
>  > the subsystem in place and it seemed to be a big help.
>  >
>  > Still, when I asked Sam to stop by and do a friendship code review, he
>  > suggested that the domain model belongs on the webserver side of the
>  wire.
>  >
>  > In our case the FACADE is a stateless session bean. Calls across the
>  wire
>  > here are many times slower (still fast though) than calls within the
>  webapp
>  > or the webserver themselves.
>  >
>  > Both Sam and I had thought we had read some suggestions on locating the
>  > model in the book and we each grabbed our copies and tried to site
>  to the
>  > other the sections that proved our stand. We quickly realized that there
>  > aren't any clear architectural suggestions about this in the book.
>  >
>  > I would think that anyone building a webapp would run into this.
>  With .NET
>  > it would be the ASP.NET server vs. .NET itself but the division is still
>  > there.
>  >
>  > Any think you have to say on this would be great.
>  >
>  > I'm currently going back and reading through the minutes of the SVP
>  Group
>  > notes, but have not seen this issue addressed.
>  >
>  > Thanks a bunch, Scott
>  >
>  >
>  > -----Original Message-----
>  > From: Eric Evans [mailto:eric@...]
>  > Sent: Friday, March 26, 2004 5:08 PM
>  > To: domaindrivendesign <at> yahoogroups.com
>  > Subject: [domaindrivendesign] Barriers to adoption / keys to
>  acceptance
>  >
>  >
>  > Here's a non-technical question I'd like to hear people's thoughts
>  about.
>  > What keeps the various aspects of domain-driven design from being
>  adopted
>  > in
>  > an organization? What helps it spread? What arguments have proven
>  > persuasive
>  > (in either direction)?
>  >
>  > For those whose organizations do DDD in some form, especially
>  where teams
>  > operate this way, how did it get started? Has it spread within the
>  > organization? What are the limits to its spread.
>  >
>  > Or, for those in places where it isn't used, what do you see as the
>  > obstacles to its adoption? Is it resistance among developers?
>  Managers?
>  > Architects? Is there a lack of awareness or knowledge about it, or
>  > skepticism about its value?
>  >
>  > Eric
>  >
>  >
>  >
>  > Yahoo! Groups Sponsor
>  > ADVERTISEMENT
>  >
>  >
>  >
>  >
>  >
>  >
>  ----------------------------------------------------------
>  > --
>  > Yahoo! Groups Links
>  >
>  > a.. To visit your group on the web, go to:
>  > http://groups.yahoo.com/group/domaindrivendesign/
>  >
>  > b.. To unsubscribe from this group, send an email to:
>  > domaindrivendesign-unsubscribe <at> yahoogroups.com
>  >
>  > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>  Service.
>  >
>
>  

--

-- 
Studying for the Turing test

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