0

I am designing an application with intention into making it a product line. I would like to extend the functionality across all layers and first struggle is with domain models.
For example, core functionality would have entity named Invoice with few standard fields and then customer requirements will add some new fields to it, but I don't want to add to core Invoice class.

For every customer I could use customer specific DbContext and injected correct context with dependency injection.
Also every customer will get they own deployment

public class Product.Domain.Invoice 
{
    public int InvoiceId { get; set; }
    // Other fields
}

How to approach this problem?

Solution 1 does not work since Entity Framework does not allow same simple name classes.

public class CustomerA.Domain.Invoice : Product.Domain.Invoice
{
    public User ReviewedBy { get; set; }
    public DateTime? ReviewedOn { get; set; }
}

Solution 2

Create separate table and link it to core domain table. Reusing services and controllers could be harder.

public class CustomerA.Domain.CustomerAInvoice 
{
    public Product.Domain.Invoice Invoice { get; set; }

    public User ReviewedBy { get; set; }
    public DateTime? ReviewedOn { get; set; }
}
  • 1
    It sounds like you're too concerned with coupling your domain models to your database design. Just make the entities your system requires and use the repository pattern to persist them. – Mr Cochese Nov 12 '13 at 10:41
  • Interesting point, I will think about it and try it out. If any issues arise I will post an update. – Codecat Nov 12 '13 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.