The MVC project I’ve talked about in my first 2 posts is still moving along. I’ve continued to learn all I can about the new ASP.NET framework, but have a lot to learn. It’s very different (read:better) from the MVC I used to do 5 years ago in the JSP days.
As the rest of the team ramps up, I thought it was important to layout the application architecture. Being a fan and student of Domain Driven Design, I followed many of the patterns discussed by Evans, as well as others. The app requires a WCF service layer, so most the typical layering will reside behind the Service layer. We’re also using LLBLGen, with Linq, as an ORM. The client is anti NHibernate, so some other ORM had be chosen and in my opinion LLBLGen is the best database driven ORM around.
The app is an enterprise critical application and I’m trying to architect in a way that will support growth, foster SOLID principals and be easy to maintain. Here’s the layers we’ll be using, with a description of each.
app.web.controllers – has controllers for MVC.
app.application – DTOs, WCF service gateway, interface for WCF proxies. Controllers will take WCF service proxy interfaces via DI.
app.service – WCF service that sends/recieves DTO’s defined in app.application. Maps DTO’s to domain objects and interacts with the next layer to call Application Services.
app.service.application – application layer for the WCF service. Contains application services that act as a facade to the domain (core) layer. This is where all infrastructure and domain functions are coordinated.
app.core – where domain objects and repository interfaces live. This is where all business logic is essentially stored.
app.infrastructure – where the repository implementations live, as well as email gateways and other infrastructure stuff.