Service contracts vs. domain objects

Say I have two interfaces to my application:

• A web front-end
• A back-end which provides data

Both of them talk to a web-service, and that web-service in turn, handles business logic and talks to a sep开发者_如何学Carate data layer, which persists the objects.

So, if each client of the web-service uses the DataContracts of that web-service, what do I need domain objects for?

Where does domain-driven design fit in here, and what advantages does it bring to my architecture?

Or is it that case that what I have already is fine, and I don't need domain objects at all?

Am I misunderstanding the meaning and purpose of domain-driven-design?

The data contracts are nothing more than messages that your client and server exchange between each other.

Your WCF service is that layer which accepts the messages and processes them so that they can be handled by your business logic.

Your domain objects would be your business logic, which accepts the processed messages, performs the necessary actions, and then applies any events that need to be applied.

If you follow a more Command-Query Separation principle (CQS), then your commands (inserts/updates/deletes) would be fired off to the WCF service and not return anything. Your client would request reads from your WCF service separate from your commands (meaning a InsertOrder command doesn't return an Order - you have to issue a separate request for that).

In all of that, your data contracts are the messages to and from your WCF service. Your domain is behind that service handling all of the business logic that needs to happen in order to make your reads as accurate as possible.

I'm answering this from more of a CQRS (command-query responsibility segregation) perspective, but I hope this explains where I'm coming from.

To answer your other question: - do you need domain objects --> I'd say yes, you should

What do I need domain objects for?

You may not need domain objects in your application. Typically, DDD would fit into a service layer in the following way: The service layer exposes its operation contracts and data contracts. Data contract classes often correspond to objects in your domain, but they are not domain objects because they don't have any behavior, they are only a representation of the data with which a particular service is concerned. Here is a simple example interaction between data contract objects and domain objects in a service:

public MyEntityDto GetMyEntity(string id) {

  var entity = this.myEntityRepository.Get(id);
  if (entity == null)
    return null;
  return new MyEntityDto(entity);

};

In this case, MyEntityDto is a DTO object for MyEntity, it serves to expose the specific properties of MyEntity which the service wishes to provide to its clients.

The value of DDD comes into play when your domain is more complex and has associated behavior:

class MyEntity {
 public void ChangeState(MyEntityState state) {
    if (!IsValidState(state))
      throw new Exception("Not a valid state.");
    // further domain logic here...
 }
}

[DataContract]
class ChangeStateCommand {
  [DataMember]
  public string MyEntityId { get; set; }
  [DataMember]
  public string State { get; set; }
}

public void Process(ChangeStateCommand command) {
  var entity = this.myEntityRepository.Get(command.MyEntityId);
  if (entity == null)
   throw new SomeException().

  entity.ChangeState(command.State);
  this.myEntityRepository.Commit();
}

In this case, the data carried my ChangeStateCommand is used to operate upon your domain entity.