Re: How-to implement the e-Commerce-System found in the "IDDD" book

Just one more comment to my last message.

I found some advice on IDDD Page 79 quote "By placing each facility in a separate Bounded Context..... would probably serve to work against the modeling principles of the Ubiquitous Language" 

Hmmh In my second implementation I've made the 3 subdomains equal 3 Bounded Contexts.
I did that because in the scenario I had in mind the 3 subdomains spoke about 3 different topics. 

Invoice-Management has a lot of terms which are very specific to Invoices.
OrderManagement deals with very different terms. Actually there is no overlap at all
And finally CatalogManagement uses also its own terms. 

The domain experts usually know about all three vocabularies. Although the degree of expertise varies. One domain expert 
knows most about invoicing the other knows more about categorization.

So maybe the first implementation is the "right" DDD implementation.
I would of course factor the different subdomains into different Modules.

I find it difficult though to decide how big the "Ubiquitous Language" can be.
In the above scenario not all domain experts will understand the whole "Ubiquitous Language". They will have a feeling what some invoice terms mean. but the not-invoice-domain experts will certainly get lost in the details of some invoice terms....




 



--- In [email protected], "j.vieten" <j.vieten@...> wrote:
>
> Hi,
> I am reading Implementing Domain Driven Design by Vaughn Vernon (IDDD). 
> 
> Actually none of my collegues or friend programmers have used 
> DDD before and I am sometimes unsure if I understand the book correctly.
> Maybe I can post an short example  to this list to see if I am on the right track?!
> 
> I'm reading IDDD Chapter 2 and looking at Figure 2.1 Page 45.
> The figure looks like:
> (I am just showing parts of the figure)
> 
> e-Commerce-System
> I-------------------------------------I
> I Catalog     I Orders    I Invoice    I 
> I Subdomain   I Subdomain I Subdomain I
> I-------------------------------------I
> Bounded Context
> 
> In the book the figure is supposed to show an example of doing wrong design.
> It advocates that all subdomains could ideally be in their own bounded contexts.
> 
> If I were to implement the e-Commerce  Domain before reading about DDD
> I would have created one IntelliJ project with an "Order" class refering to an "Product" class. 
> and  order would also contain a list of invoices.
> 
> Now having read the first 45 pages of IDDD I would do the following:
> 
> I would create 3 IntelliJ projects products, orders and invoices.
> An order would be only associated with a product by a simple product-ID.
> An invoice would only know about its order by means of a order-ID.
> Now I could imagine that these three subprojects could even be deployed on their own servers and
> offer their services trough a REST APi.
> 
> Let me just go through two usecases:
> 
> Use-case "Deleting an Order."
> 
> With the first implementation this is very easy. 
> I just need to call the order's delete method which also just deletes its contained invoices.
> 
> With the second implementation I probably need some kind of event-system so that the
> invoice subdomain can react on a  Order-Delete Event.
>    
> Use-case "Reporting of all invoices grouped by a catalog item"
> 
> In the first implementation I would find all products of an catalog and then find the  associated  orders.
> I would  then just iterate over the invoices to produce the report.
> 
> In the second implementation I would do basicly the same steps. But since I'll have to deal with three
> systems the "services" have to do internally a lot of lookups based on product and order IDs. So I do expect to
> performance-wise to need to tune here a lot.
> 
> I just want to make sure that I am on the right "path" on  understanding the book.
> Could  my second implementation qualify as a DDD Model?
> 
> Many Greetings
> John
>



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