I still looking best practice for domain model validation. Is that good to put the validation in constructor of domain model ?  my domain model validation example as follows: public class Order {    private readonly List<OrderLine> _lineItems;    public virtual Customer Customer { get; private set; }    public virtual DateTime OrderDate { get; private set; }    public virtual decimal OrderTotal { get; private set; }    public Order (Customer customer)    {        if (customer == null)            throw new  ArgumentException(Customer name must be defined);        Customer = customer;        OrderDate = DateTime.Now;        _lineItems = new List<LineItem>();    }    public void AddOderLine //....    public IEnumerable<OrderLine> AddOderLine { get {return _lineItems;} }}public class OrderLine{    public virtual Order Order { get; set; }    public virtual Product Product { get; set; }    public virtual int Quantity { get; set; }    public virtual decimal UnitPrice { get; set; }    public OrderLine(Order order, int quantity, Product product)    {        if (order == null)            throw new  ArgumentException(Order name must be defined);        if (quantity <= 0)            throw new  ArgumentException(Quantity must be greater than zero);        if (product == null)            throw new  ArgumentException(Product name must be defined);        Order = order;        Quantity = quantity;        Product = product;    }}Thanks for all of your suggestion.
Where we should put validation for domain model
design patterns;domain driven design;validation
There's an interesting article by Martin Fowler on that subject that highlights an aspect most people (including me) tend to overlook:But one thing that I think constantly trips people up is when they  think object validity on a context independent way such as an isValid  method implies.I think it's much more useful to think of validation as something  that's bound to a context - typically an action that you want to do.  Is this order valid to be filled, is this customer valid to check in  to the hotel. So rather than have methods like isValid have methods  like isValidForCheckIn.From this follows that the constructor should not do validation, except perhaps some very basic sanity checking shared by all contexts.Again from the article:In About Face Alan Cooper advocated that we shouldn't let our ideas of  valid states prevent a user from entering (and saving) incomplete  information. I was reminded by this a few days ago when reading a  draft of a book that Jimmy Nilsson is working on. He stated a  principle that you should always be able to save an object, even if it  has errors in it. While I'm not convinced that this should be an  absolute rule, I do think people tend to prevent saving more than they  ought. Thinking about the context for validation may help prevent  that.