DDD : nested aggregates and many to many relationships

Question

I'm currently working on a Publishing Bounded Context. The main players in this context are Product and Listing.

Product : can be listed in multiple marketplaces. One Product Many Listing.

Listing : can have many products because some marketplace support variation listing. One Listing Many Product.

Based on the above I have a Many-To-Many relationship between Listing and Product.

I created an aggregate for both. The Product aggregate which contains listings and the Listing Aggregate which contains products.

Is it acceptable to have Listing defined in both aggregates or should I define Listing once to be used in both aggregates?

First Listing would be within the product aggregate because the product AR has a factory method that enforces rules when creating Listing(such as avoid duplicate listing in same marketplace and ensure we have stock qty for listing)

Second Listing would be an aggregate root which can contains info from many Product needed at the moment of publishing. This way I can create method on Listing to map it to a schema definition provided by different marketplaces (such as Ebay and Amazon). Also I want to be able to persist Listing independently from Listings within the same Product.

Do the two aggregates have too much overlap with duplicate definitions ? Is this to be expected within one bounded context?

Also how can I keep the duplicate representation of Listing synchronize with each other?

Answer 1

First Listing would be within the product aggregate because the product AR has a factory method that enforces rules when creating Listing(such as avoid duplicate listing in same marketplace and ensure we have stock qty for listing)

Should a product know its own stock, its own marketplaces, its own listings and create listings too? This is too much responsibility for an entity! I would suggest to let a ListingFactory check the stock and the marketplces with other services or repositories that hold this information.

Is it acceptable to have Listing defined in both aggregates or should I define Listing once to be used in both aggregates? Also how can I keep the duplicate representation of Listing synchronize with each other?

Avoid cyclic dependency between Product and Listing and a mess by maintaining a single list (have a look at this question for a similar tangle: How to design many-to-many relationships on deletion?). Seems to me you should have an aggregate of marketplaces, which contains your listings. You could setup a marketplace service or repository that gets all Listings if you need to access all listings based on a product (like in the ListingFactory I proposed).

Do the two aggregates have too much overlap with duplicate definitions ?

Your definition of product "can be listed in multiple marketplaces" is not a very satisfying definition, because after reading this definition the question still remains: What is it then that can be listed? At its core a product can be defined without knowledge of listings, but within this context it probably would still be better to explicitly name the relationship. Since a (product) listing can not be defined without a product, but a product can be defined without a listing. They need not be duplicates. I would expect your product to be completely listing-unaware, but related to listings within the context.

Is this to be expected within one bounded context?

All definitions build on each other, so within any context you can expect overlap, duplication, synonyms, extensions, near similarity, cross-referencing, different types of relationships, etc. It requires quite a bit of investigatory consciousness to separate the primary from the secondary, the predicates from the subjects and objects, the nucleus from the membrane. However, this is also what makes it so much fun :)

definition of word: "A single distinct meaningful element of speech or writing, used with others (or sometimes alone) to form a sentence.."

definition of sentence: "A set of words that is complete in itself, typically containing a subject and predicate, conveying a statement, question, exclamation.."