1

So my question is very much related to this one: Entity persitance inside Domain Events using a repository and Entity Framework?

EDIT: A much better discussion on the topic is also here: Where to raise persistence-dependent domain events - service, repository, or UI?

However my question is rather more simple and technical, assuming that I'm taking the right approach.

Let's suppose I have the following projects:

MyDomainLayer -> very simple classes, Persitence Ignorance, a.k.a POCOs
MyInfrastructureLayer -> includes code for repositories, Entity Framework
MyApplicationLayer -> includes ASP.Net MVC controllers 
MyServicesLayer -> WCF-related code 
MyWebApplication -> ASP.Net MVC (Views, Scripts, etc)

When an event is raised (for example a group membership has been granted), then two things should be done (in two different layers):

  1. To Persist data (insert a new group membership record in the DB)
  2. To Create a notification for the involved users (UI related)

I'll take a simple example of the last reference I wrote in the introduction:

The domain layer has the following code:

public void ChangeStatus(OrderStatus status)
{
    // change status
    this.Status = status;
    DomainEvent.Raise(new OrderStatusChanged { OrderId = Id, Status = status });
}

Let's assume the vent handler is in MyApplicationLayer (to be able to talk to the Services Layer). It has the following code:

DomainEvent.Register<OrderStatusChanged>(x => orderStatusChanged = x);

How does the wire-in happen? I guess is with structuremap, but how does this wire-in code looks exactly?

Community
  • 1
  • 1
Jorge Alvarado
  • 2,664
  • 22
  • 33

2 Answers2

4

First, your layering isn't exactly right. Corrections:

Application Layer - ASP.NET MVC controllers are normally thought of as forming an adapter between your application layer and HTTP/HTML. Therefore, the controllers aren't themselves part of the application layer. What belongs in application layer are application services.

MyServicesLayer - WCF-related code. WCF implemented services are adapters in the hexagonal architecture referenced by Dennis Traub.

MyWebApplication - ASP.Net MVC (Views, Scripts, etc). Again, this forms an adapter in a hexagonal architecture. MVC controllers belong here as well - effectively they are implementation detail of this adapter. This layer is very similar to service layer implemented with WCF.

Next, you describe 2 things that should happen in response to an event. Persistence is usually achieved with committing a unit of work within a a transaction, not as a handler in response to an event. Also, notifications should be made after persistence is complete, or in other words after the transaction is committed. This is best done in an eventually consistent manner that is outside of the unit of work that generated the domain event in the first place.

For specifics on how to implement a domain event pub/sub system take a look here.

eulerfx
  • 36,769
  • 7
  • 61
  • 83
  • kudos eulerfx and Dennis, thank you very much, this was a crash course on architecture. I think I have some homework to do and read this hexagonal architecture. Many thanks. – Jorge Alvarado Nov 13 '12 at 07:15
3

My first recommendation, get rid of the notion of Layers and make yourself familiar with the concept of a Hexagonal Architecture a.k.a. Ports and Adapters.

With this approach it is much easier to understand how the domain model can stay independent of any of the surrounding concerns. Basically that is object-orientation on an architectural level. Layers are procedural.

For your specific problem, you might create a project containing the event handlers that project events into the database. These handlers can have direct access to the database or go through an ORM. You probably won't need any repositories there since the events should contain all information that's needed.

Dennis Traub
  • 50,557
  • 7
  • 93
  • 108