A proxy is not necessarily a problem. It largely depends on the context and on the
But there are too many question marks open here, so I like Casey's recommendation here.
I'b probably start something similar: "Aggressively search for domain experts". Sometimes
this is a feasible way, somatimes it's hgarder, but will give you a warning sign if your
proxy DE is dragging you off track or not.
I've been in a similar situation and I was really worried, because our DE was not a real DE
but had been involved in the previous implementation of the application (15 years before)
- he knew the application, and though he knew the domain.
- he wasn't to inclined to admit that things could have been done differently.
Later it turned out that the users were so used to the old application that they liked the
new one just because there was nothing new to learn. No breakthrough, no real
competitive advantage, but the same old stuff... with a different technology. Maybe doing
full DDD in such a scenario could be a waste. On the other hand sometimes older version
of the application are part of the overall domain, and this must be considered too....
--- In email@example.com, Casey Charlton <casey@...> wrote:
> No experts because?
> If you are an ISV, start a simple model, phone 3-4 of your best customers,
> buy them lunch and ask them to rip your ideas to pieces
> 2009/2/2 Colin Jack <colin.jack@...>
> > > Te proxy *thinks* they know more than all the customers combined, the
> > > whole point of DDD is that they almost certainly do not.
> > So in this case I think we should consider falling back to simpler
> > methods where the tech team design solutions that suit them, forgetting
> > about a shared model and UL.
> > These simpler methods are a liability I admit, but they are easier for
> > junior developers to understand and in my experience are as successful
> > as DDD *if* you don't have domain experts to discuss the model with.
> > Am I wrong?