Is this Domain-Driven Design?

Question

To Domain-Driven development experts out there...

I am trying to really grasp the concept of DDD. So far I have been designing my models to be data driven rather than domain driven. I have read a couple of articles about DDD and seemed really interesting, especially for large-scale applications. So I am trying to tailor my models to do exactly that.

I have say a customer entity that exposes a method FreezeAccounts which would disable all customer accounts. This method is not concerned with data access (based on the Persistence Ignorance rule). It updates a flag on each customer account (which is loaded on demand) and saves changes to a database. Is that correct based on this model? I have read that in DDD there is not necessarily just one class per table entity. Should this functionality be in a separate class? Here is some sample code:

public class Customer : ICustomer, ICustomerAction
{
    #region Initialization
    public Customer()
    {
    }

    internal Customer(ICustomer view)
    {
        this.CustomerId = view.CustomerId;
        this.Name = view.Name;
        this.Email = view.Email;
        this.IsActive = view.IsActive;
    }
    #endregion

    #region Instances

    private AccountCollection _accounts;

    #endregion

    #region Properties

    #region ICustomer

    public int CustomerId { get; private set; }
    public string Name { get; set; }
    public string Email { get; set; }

    #endregion

    #region Derived

    public AccountCollection Accounts
    {
        get
        {
            if (_accounts == null)
                _accounts = Account.GetListByCustomerId(CustomerId);
            return _accounts;
        }
    }

    #endregion

    #endregion

    #region Methods

    #region CRUD

    // Data Access Object accepts interface ICustomer
    internal void Update()
    {
        CustomerDb.Update(this); 
    }

    #endregion

    #region ICustomerAction

    // Exposed business Persistence Ignorance action
    internal void FreezeAccounts()
    {
        foreach (Account account in this.Accounts)
        {
            account.IsEnabled = false;
            account.Update();
        }
    }

    #endregion

    #endregion
}

Answer 1

With DDD you want to keep a clear understanding of what is an entity (has a unique ID, and persisted as an individual unit), what is an entity root (the entities that you want to expose to the outside world), and what is a service (code that manages interactions between entities).

How an item is persisted in the DB can be totally different from its entity object - but since you only deal with entities the outside world doesn't have to worry about that, and it is abstracted out to the DAL.

In your example you're making good use of programming to an interface (the I in SOLID), which is good, but without knowing the intent of your system it's hard to say whether this sample is following DDD or not.

Answer 2

First of all, in DDD as in other architectures, the Data Access Layer must be separated from the domain and the business logic, so no CRUD operations into the entity.

So to answer, yes, create a separate layer (no only a class) to read/write data on the storage, in particular in DDD you can use the Repository and Unit Of Work patterns by Martin Fowler.

If you want an example of DDD look here.

Note: I've to publish a new revision of my DDD architecture "view" on NuGet.