Re: Conceptual Vs Data Vs Domain model

Thanks Paul for responding. 

 I'm little surprised at your suggestion to model the Catalog as a data model (relation model). I mentioned about a behavior called Remove Expired Products. Let us assume, the business rule is little more complex than just using the date to find the expired products. There can be rules like if the expiration is today, move the products to a different catalog which will be immediately moved to a different brick and mortar store. The system will send an event to a different BC to tell the store that 'Your have got more products to sell today'. By considering this behavior, don't I have to consider a domain model rather than a data model? Isn't it always to go the domain model so it can embrace any new behaviors in the future?
 

 Appreciate your feedback.
 

 ---In [email protected], <paul@...> wrote :

 Two bounded contexts typically means two models, each with their own ubiquitous language and each addressing a different set of business scenarios. Keep that in mind. If they share the same language and conceptual model then it's more likely to be one bounded context, with perhaps multiple modules or some other organizing structure. 

 This is still all too abstract for me. Either model could still work.
 

 I'd be asking questions like: How many catalogs will you have? Why do you need to separate products that way? How many products? How many categories? Which things change often? If you removed a catalog, would you remove all the products as well, or do they exist conceptually independent of the catalog? Which of the features you list are likely to be the most critical to the application? Etc.
 

 The way you've presented it now, your catalog context operations could easily be done purely in a relational database. Why do you even need a domain model there? Forecasting context seems kinda trivial too, but different tax and sales price strategies could be challenging. I suppose you are just giving us a simplified example, which also contributes to why this is hard to advise you on which way to go. What I would do if I was working with someone at this point is create some real business examples to talk and walk through, then write some code & tests, or pseudocode, to try out the model.
 

 I realize this probably doesn't help you much, but it's how I'd approach it. See http://domainlanguage.com/ddd/whirlpool/ http://domainlanguage.com/ddd/whirlpool/.
 

 Paul.