I'm looking for a design pattern that might work for this class I am working with. This main class is an entity using Domain Driven Design.
public class TimeCard() : ITimeCardHeader
{
public int TimeCardHeaderID { get; pivate set; }
public int ContractorID { get; internal set; }
public System.DateTime Date { get; internal set; }
public StateEnum State { get; protected internal set; }
public System.DateTime CreatedDate { get; internal set; }
public Update( ITimeCardHeader header)
{
//validation logic.
//assign values e.g. This.ContractorID = header.ContractorID
// create and send domain event "Time card change"
}
}
I would like to ask Questions(functions) of the timeCard object to determine if it could be edited. However, the business rule of if a timecard can be edited really is based on who you are.
So my Idea is to ask questions via an interface
interface ITimeCardCreater{
bool CanEditTimeCards{get;}
int? ContractorId {get;}
}
Then I could have higher level classes Create a user then add methods to my TimeCard like.
timecard.CanEdit(ITimeCardCreator);
My Question is where should that type of logic live. I had it directly on the Timecard object but I now think that it should be a class unto itself as it's getting large.
Edit as suggested by king-side-slide Rename interface to ITimeCardCreater.
Question: is there a design pattern that removes logic from a domain model that is exclusively used by that model to answer questions against it.
Aspect Oriented Programming (AOP)
- but for C#, you'd need a third party library to support that. – Bernhard Hiller Jan 16 at 8:51