DDD with EF Code First - how to put them together?

Question

I am learning DDD development for few days, and i start to like it.

I (think i) understand the principle of DDD, where your main focus is on business objects, where you

Answer 1

Update I no longer advocate for the use of "domain objects" and instead advocate a use of a messaging-based domain model. See here for an example.

The answer to #1 is it depends. In any enterprise application, you're going to find 2 major categories of stuff in the domain:

Straight CRUD

There's no need for a domain object here because the next state of the object doesn't depend on the previous state of the object. It's all data and no behavior. In this case, it's ok to use the same class (i.e. an EF POCO) everywhere: editing, persisting, displaying.

An example of this is saving a billing address on an order:

public class BillingAddress {
  public Guid OrderId;
  public string StreetLine1;
  // etc.
}

On the other hand, we have...

State Machines

You need to have separate objects for domain behavior and state persistence (and a repository to do the work). The public interface on the domain object should almost always be all void methods and no public getters. An example of this would be order status:

public class Order { // this is the domain object  
  private Guid _id;
  private Status _status;

  // note the behavior here - we throw an exception if it's not a valid state transition
  public void Cancel() {  
    if (_status == Status.Shipped)
      throw new InvalidOperationException("Can't cancel order after shipping.")
    _status = Status.Cancelled;
  }

  // etc...
}

public class Data.Order { // this is the persistence (EF) class
  public Guid Id;
  public Status Status;
}

public interface IOrderRepository {
  // The implementation of this will:
  // 1. Load the EF class if it exists or new it up with the ID if it doesn't
  // 2. Map the domain class to the EF class
  // 3. Save the EF class to the DbContext.
  void Save(Order order); 
}

The answer to #2 is that the DbContext will automatically track changes to EF classes.