Reputation: 11
I am currently trying to implement DDD on an ecommerce application. This is on an already existing application that used ntier architecture. I am taking it one step at a time trying to generate domain objects and domain logic for products but i am encountering some issues in the implementation.
First of all, for context, the products have been mapped from an already existing table which has a one to one persistance model for entity framework orm. The tables in question are Product, Variants, Options and Instances.
A variant is a family of characteristics for the product such as SIZE or Material;
An option belongs to a Variant and determines the choices within it such as Size: XL, L etc. They have a price modifier on them for the more expensive options.
An instance is an unique combination of one option from each variant, which in turn generate a specific price/SKU and other values. `
public class Product
{
public Guid Id { get; private set; }
public string Title { get; private set; }
public List<Variant> Variants { get; private set; }
}
public class Variant
{
public Guid Id { get; private set; }
public Guid ProductId { get; private set; }
public string Title { get; private set; }
public List<Option> Options { get; private set; }
}
public class Option
{
public Guid Id { get; private set; }
public Guid VariantId { get; private set; }
public string Name { get; private set; }
public decimal PriceModifier { get; private set; }
// ... constructor, methods, etc.
}
public class Instance
{
public string Sku{ get; private set; }
public decimal Price{ get; private set; }
public List<<VariantId, OptionId>> Combination { get; private set; } }`` Note : These examples are simplified to provide context without too much unnecessary details.
Secondly, the actual problem :
The persistence handles their own models in the infrastructure layer. This is done through repositories for each db set. In some cases, a transaction is initiated in a repository to ensure no partial updates are done. This is done for when updating the product details (title etc) and modifying a price on an option as it has to regenerate the instances with the new price.
In the product class, i have a private list of variants that i can modify only through a call to a public function to add, remove or update some properties. Same goes for variants, all properties cannot be set directly.
When i get an update from the front-end to update the variants, up until now i would receive a list of Variants and just override everything in the database. With DDD, this is a bit trickier as i first have to fetch the product, call crud functions on it which in turn will call crud functions on the Variants and so on. While this ensures that my product is in a valid state and all changes are correctly executed, I fail to understand how i mapp that logic to a repository change. Should the product have access to a repo of itself and send commands to the infrastructure layer?
Should i just validate my update model and call the repositories without going through the crud functions in the product domain class?
I am kind of confused how DDD interacts with the repository pattern and especially how it can deal with multiple updates on a more complex class.
Upvotes: 1
Views: 151
Reputation: 771
I guess you need to re-consider about your design. Product
can be treated as the AggregateRoot
. And as I understood your question, Variants
and Options
can be treated as Value Objects. So any update to the Variants
or Options
should be happen through the Product(AggregateRoot)
to make sure your product is in a valid state. Because now it is your consistency boundary.
You can have a repository
for the Product
. If you treat the Product
as AggregateRoot
then you have to Persist (root entity and all its children entities) as a whole. Because Aggregate
is consistency boundary.
Upvotes: 0