Re: I think the penny has finally dropped ...

Ok so I would model the problem domain and not worry about the 
application until the problem domain had been completed. Then if 
there are aspects of the infrastructure that support Domain Model 
that I didn't need to use in the current application I could choose 
to not implement them until needed in a future application? 

My problem was that I was looking at the domain from the view of the 
application that was going to use it, I should have started with my 
design being domain driven, hence Domain Driven Design (my *ding* 
moment). This would make the model instantly reusable, because the 
model will be true to the real domain.

I am sure this is something that all of you understand but I am a 
newbie and am trying to get my head around things. It all makes 
perfect sense though! :0)

Thank you for your patience!

--- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@...> 
wrote:
>
> I think the model you have is fine. Realistically speaking, if the
> entities are currently stored in a database, then I'd predict there 
is
> a high probability that the next set of requirements will be to be
> able to add/update/delete them. If you are currently using in-memory
> repositories, then I'm undecided. So this would influence what the
> public interface of the repositories looks like; if you think you'll
> be doing add/update/delete in the future, I'd go with your
> exception-throwing approach.
> 
> --- In domaindrivendesign <at> yahoogroups.com, "Scott Millett" <scott@>
> wrote:
> >
> > 
> > I am modelling an E-commerce store and I have a product (entity) 
which
> > contains a brand (entity) association and category (entity) 
association.
> > Now my web site which will use the Domain Model does not need to
> > Add/Update/Remove products, brands or categories it only needs to
> > display them. I believe I have modelled the domain correctly by 
creating
> > the product, category and brand as entities - even though in this
> > instance I won't be using this behaviour. They are also their own
> > aggregate roots because you don't need to go through a Product to
> > add/remove/update a brand or category, similarly with 
add/remove/update
> > of a product.
> > 
> > I guess this means that in the future if I need to write say a 
windows
> > application that gives staff the ability to update/add/remove a
> > category/brand/product I can reuse the domain model.
> > 
> > Because for the purposes of this web application I will not be 
using the
> > add/remove/update methods on the repositories for the above 
entities so
> > I have just added stub code that will throw "The method or 
operation is
> > not implemented" error if someone tries to persist an object. I 
can then
> > at a later date code this logic if needed. - is this good 
practice?
> > 
> > This means my Model will be a true representation of the real 
domain and
> > can be reused for any purpose, is this what the essence of DDD 
is? Model
> > the problem domain and then start on the application?
> > 
> > Cheers
> > Scott
> >
>

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