I could not get the first link to open. My computer could not find the domain.

I am (constantly) searching for ways to improve my application designs. This post has already fallen out-of-date with my current designs which somewhat follow with what you have suggested.

Currently, I do use a persistence layer which contains my repositories, data connections, other data sources, etc. This layer also contains my domain model.

I also use a Service layer (model) which contains the service classes.

The user interface items (controllers / views) reside in my main MVC project along with some helper classes that return HTML to the views.

While I like the idea of having a domain model in the service layer and kept hidden from the other layers, I’ve ran into problems that forced me to revert back to my current design just to get the work done.

I really like this design: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

I think the Onion Architecture keeps your code cleaner and will help limit rewriting and retesting code. You should check it out. I think this design would go well with your ideas.

So far the problems I’ve seen with Onion Architecture are:

- The outter-most layer (that starts the application) needs to be a Dependency Injection layer and I have not figured out how to make this work with ASP.NET MVC.

- When data is passed from the repositories (which have their own model) to the service layer (the domain model), mapping must be done to copy the data from how the database is designed into how you want to use it in your model. Changing something in the database becomes a pain because you have to update your database model and the mappings.

- Creating view models began to get too bulky, but this was probably due to me trying to use the same view model for many different views. It probably would have worked better by creating a separate view model for each view.

I want to migrate into the Onion Architecture design, but I still need to resolve a few more issues.

I think your diagram should have three layers in which everything else resides: Persistence, Model, and Presentation…

The three tier architecture was suggested by David Anderson in the following post and I agree with most of his approach: http://www.uidesign.net/Articles/Papers/UsingMVCPatterninWebInter.html

There should be a Persistence layer consisting of the Repositories, (Database Connection and Database), and (Data Connection and Other Data Sources).

The Model layer should be visible in the diagram. The Model layer should include the Services and the Domain Objects, in addition to the business/problem logic.

The Controller is a logic unit handling input, so it it should not need direct access to the Domain Objects. Dealing with the Domain Objects should be limited to Model layer entities.

You may also want to give some thought about peeling out the View (output) and Controller (input) into a Presentation layer, as suggested by both David Anderson and Aviad Ezra, although I don’t agree with everything Aviad Ezra says either, as it does not quite fit the next generation web apps, but comes very close IMHO: http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html

Merging what you propose in with what is proposed in the other two posts, plus making the browser a client-side Presentation layer, makes for a very workable paradigm for the next generation browser applications (notice I did NOT say “web applications”). I’d post a diagram, but these comments are text only.

Just my 2 cents.