Entities relationships: One-To-Many vs. Many-To-One

[František Maša]

This one still occupies my mind. How do you model 1:N relationships.

Consider having a category and product (typical e-commerce scenario).

Every product can be associated to only one category.

Should I model such relationship as: (pseudo-code)

Product
{
    string category;
}

Category {}

or on Category's side:

Category
{
    Product[] products;
}

Product {}

Second way seems more logical (products are organized in categories) but brings other problems (imagine category with 10k products and every time you want to add product to collection, you must check whether it contains that product or not.

The first way makes it easier. There is always one Category and Product in memory, but Category entity without behavior seems awkward.

Any suggestions?

[Tom Janssens]

Category might be a value object?

Op dinsdag 21 juli 2015 15:36:29 UTC+2 schreef František Maša:

[Alexandre Potvin Latreille]

Models should be crafted to support commands and protect invariants while remaining expressive and true to the ubiquitous language. That's how you define the associations of your model.

If the only invariant that constrains the Product-Category relationship is that a Product has to be categorized, then Product could hold the category value (or the identity of the category if it's an AR).

Another fictive invariant could be that a Category may only be associated with a maximum of N products. In that case, a Category may hold a collection of ProductId values or perhaps ProductCategory values because you need a boundary that includes all the associations in order to strongly enforce the invariant.

There are times where strongly enforcing an invariant may require a very large consistency boundary (a huge aggregate), one that may not be scalable. At that point, you will have to turn to business experts in order to see if the rule is a true invariant and understand the business impact of violating that rule. You may found out that eventual consistency is acceptable, either through an automated process or a manual one (e.g identity categories that are busting the rule so they can be addressed).

I do not have a lot of experience yet, but from what I could understand so far, invariants are key for modeling aggregates... 

[Ben Kloosterman]

 Your think far to much in lower level / relational DB terms and imposing the infrastructure on the design . There are many ways of modelling this. The question is how does the business do it .. what is the real relationships . You may even find ProductA has a different relationship to ProductB ( It may have no , none or multiple categories) .

The question which si better should be obvious by the way the business uses them , are there departments that manage certain products ? Why does category exist - is it a business term or just a grouping for the web site  / GUI  etc etc .. Are categories value types or Entities   - there are cases where you may have 2 categories with the same name and no id - it depends category means to that business. Once you have that then you can model it and you would not be asking such a question the business normally knows whether products belong to categories ( eg different org units)  or visa versa.

Than look at the implementation -eg  you may dump the entire category with all products as a single entity. Adding a singe product would not be an issue there either just store it as a dictionary in the domain when you load the blob and consider this data often changes very rarely so benefits from caching .  Though again these are lower level concerns first it has to match what the business does . Then when you build it and find issues optimize.  How does the business add a product now ? How do they ensure there is no duplicate ?

Categories are often many to many as well.

Regards,

Ben