Pending Updates Module - Domain Entity or Value Object?

Question

I am in the process converting a large classic ASP web application to ASP.Net MVC with domain driven design. While much of my domain fits well with DDD, I keep running into situations where a pure DDD approach is not appropriate. For example the read side of my application varies significantly from the write side. No problem, I created a separate read model, and implemented a simplified version of CQRS (no event sourcing, no separate db). Another issue was bulk database operations. No problem, that is being implemented as a service. Here's my current quandary. Our system allows users to make changes to the system that are effective on some future date. To accommodate this we have a database table that stores the pending changes until the effective date. On the effective date, an automated task runs and performs the actual database updates. The update task can include domain logic, so that part fits with DDD and is not a problem. To help visualize what is going on, here is the class that handles the pending update:

public class PendingChanges
{
    public int EntityID {get; set;}
    public string FromTable {get; set;}
    public string DetailField {get; set;}
    public string NewValue {get; set;}
    public DateTime EffectiveDate {get; set;}
    public DateTime EnteredDate {get; set;}
    public int UserID {get; set;}
    public string UserName {get; set;}
    public string UserArea { get; set; } 

   // Business logic and validation here? 
} 

As you can see this is a generic class that can handle updates to various database tables. It basically stores the database column that is being updated, the new value that the column will be, the table that it belongs in, the effective date and some logging data.

So here are my questions: Should the logic that collects the pending update and stores it in the pending updates table be modeled as a domain object or should it be handled some other way, for example as a service?

To put it another way is PendingChanges itself a domain entity with its own domain logic? There are some business rules that apply to PendingChanges as distinct from the entities that the changes are taking place on. For example what constitutes a UserArea could be considered a business rule as would be legal values for FromTable, not to mention validation.

Or is PendingChanges a value object since it is reusable across different domain objects? If that is the case does it make more sense to use PendingUpdatesService?

Answer 1

Is part of the Domain the concept of doing db updates i.e are you building database management/reporting software? If PendingChanges has a meaning for your Domain then maybe is an entity, although this technicality matters less, getting the proper domain modelling is much more important. If PendingChanges is a class that your app is using to update (domain)things in the db, then it has nothing to do with DDD nor with your domain. It is a part of your infrastructure. Good OOP is still needed though, but no DDD buzzwords here.

Btw, if an object has an id, it usually is an Entity.