N-Layer Architecture

Question

I'm in the situation that I have to design and implement a system from the scratch. I have some questions about the architecture that I would like your comments and thoughts on.

Quick Info about the project: It's a data centric web application.

The application will be built on Microsoft .NET Framework 4.0 with MS SQL SERVER 2008 database.

Requirement:

1. Rich UI and robust
2. Multi-device support (every browser and on every device)
3. Loosely coupled

Below is the architectural diagram I have built:

Briefing of the architecture

1. Presentation layer : HTML5/ASP.NET MVC + JQuery (Web application for multi-device support in first version)
2. Distributed Services : WCF (XML/JSON/JSONP)
3. Domain Layer(Business Layer) : All business logic
4. Data persistence (DAL Layer) : Entity Framework 4.0 with database first approach. POCO entities are generated and separated out using T4 template
5. Infrastructural Layer: Contains common libraries like POCO entities, Exception Handling, logging etc

My Concerns :

1. As application is to be built loosely coupled so in future if business requirement grows new modules can be easily plugged in without affecting the architecture. So I thought of using the Repository pattern along with IoC and DI (can be Unity/Ninject/Sprint.NET or any other)
2. WCF with both XML and JSON support
3. Distributed Service Layer to place IoC & DI
4. Exception Handling & Logging using Enterprise Library 5.0

Looking for valuable comments and suggestions. If I am doing anything wrong please put me in right direction.

Answer 1

It makes sense that the WPF, WinForm etc UIs should call the WCF layer. I'm assuming that it's a business requirement to have multiple UIs, otherwise if you can only have one UI a responsive web UI is the most flexible choice.

However, I don't think your MVC UI needs to use the WCF layer. It could call the domain layer directly. That would be faster and remove a pointless layer.

Obviously, that would only work so long as you don't put any logic in your WCF layer. And the WCF layer really shouldn't have any logic in it.

You also state that you want to place IoC & DI in the Distributed Service Layer. That doesn't make much sense in terms of your MVC UI. You'll need to use DI in the MVC project so you can unit test the controllers.

Answer 2

How come that the architecture diagram doesn't use the domain layer for ASP.NET?

It seems to me that you may be overarchitecturing your application. Also, while it looks great to support 6 (or so) different front-end technologies, the effort to maintain all of them will be horrendous. I'd stick to one technology for the front-end - most likely HTML5 with client-side MVC or similar.

Answer 3

I would suggest the following comment: right from the outset your approach will create tight coupling. This goes directly against your requirement #3 "Loosely coupled"

In your diagram you have defined two modules. Main module, and Module 2. I would guess that these two modules are quite distinct from each other. What I mean by this is that you could develop them completely separately and then plug them in, because the business concerns they address are different.

However, your current architectural approach:

• Couples Main Module and Module 2 data into the same database
• Couples Main Module and Module 2 business objects into the same business layer
• Couples Main Module and Module 2 services into the same service layer
• Couples the deployment and management of Main Module and Module 2

What may be worth considering: Build Main Module and Module 2 as separate vertical service stacks.

What I mean is Main Module and Module 2 become Main Service and Service 2

Each service has it's own database, it's own business layer, it's own services layer and it's own UI components.

However, this raises the concern: how can Main Service and Service 2 both work together to create my product?

To address this:

1. At the UI end, you stitch your front end together by using client-side code to load responses from the Main Service and Service 2 into one view.

2. At the back end you use publish subscribe messaging to allow Main Service to subscribe to events happening in Service 2 and vice versa.

This will result in an application built from the ground up on top of loosely coupled vertical service stacks, which maintain consistency by the asynchronous exchange of messages.

If you then need to add in a new module to your application, you can create a new service stack which supports the desired capability and wire it up with little or even no change needed to the other stacks (ideally the only reason to change existing stacks would be that they want to subscribe to events from the new module).

It's a very different approach to the one you're suggesting, but one which allows you to meet the requirement for loose coupling better, in my opninion.

Answer 4

Looking at your diagram I have a couple of points I'm not clear on:

• Where is the domain model? Domain Core or the 'model' in the persistence layer?
• How does the domain layer interact with the data access layer? The interaction is not as clear as between the service/application layer and domain layer.
• What the difference between a repository in the domain layer and a repository in the data access layer? I usually make the distinction of having 'model repositories' in the domain layer which act upon domain model objects, and 'data gateways' in the data access layer which act upon DTO's.
• What is domain core? Is this the implementation of the application layer transactions?
• Does there need to be a further abstraction of the persistence framework? (EF)