DDD中的实体继承

Question

I am trying to design a Domain Model of an E-Commerce system using DDD guidelines. I have a situation where I have 2 different types of Products. One product is "Item" and the other product is "Package" (Group/Bundle of Items). My domain model so far looks like this

public abstract class Product : IAggregateRoot
{
    public string ProductId { get; protected set; }

    // Many to Many relationship between Item and Package
    protected List<ItemPackageRelationship> ItemPackages => new List<ItemPackageRelationship>();

    protected List<Image> Images => new List<Image>();

    // Other properties shared between Item and Package
}

public class Item : Product
{
    // All properties and methods specific to Item

    public void SetImages(List<string> images)
    {
       // Set images for Item has its own business logic

       // Example: number of allowed images, size of image etc
    }
}

public class Package : Product
{
   // All properties and method related to package

    public void SetImages(List<string> images)
    {
       // Set images for Package has its own business logic

       // Exampe: number of allowed images, size of image etc
    }
}

All the behavior is defined inside Item and Package class and Product class just has shared properties. Initially I was thinking to create 2 complete separate Aggregate roots (Item and Package) and no Product entity. The only reason I need Product is because of the Unique ProductId in the system. And all the relationship with other entities (like Images) needs to based on ProductId.

I am not 100% confident what I am designing is correct and need some input here. Creating a Base entity just to share some properties is against any principle of DDD? Is there anything else you guys would suggest to improve the design of my Domain Model?

Thanks very much in advance.

Answer 1

I think inheritence of entities should be driven by behavior, not by properties. In other words you should look at other busines code, not at entities itself. If you see relatively many places which should operate with an Item and with a Package in the same manner when iheritence can be used (but is not strictly necessary). Inheritence is not reasonable if the single reason is sharing an unique identifier.