Framework Architecture

Application Architecture Framework

Solution Projects

1. Core – The Core project represents the cross-cutting location where you would place the following list of items. What this means is that you would reference the Core project in virtually every other project in the solution.

   1. Contracts – These are the interfaces that would be used for the Dependency Injection mappings.
   2. Enums – The central location for all enumeration that the application would use.
   3. Helpers – This represents a central location where helpers would be places. Each project in the solution may have the need for a sharable help class, this would be the place to put that.
   4. ViewModels – These are the object that would be used as view models for the MVC views and also the data transformation object (DTOs) that each layer would be able to pass along to the next.

2. Data – The Data project is where the repository classes belong. This is also where the Entity Framework .edmx model would be created. When a repository class requests data from the model, the entity would be immediately transformed into a ViewModel and then returned so that the domain can take it, perform any business logic and then pass it along to the UI.

3. Domain – The Domain project is where all business logic would be placed. Beyond that, this is where aggregate roots would be references to gain access to “Child” information.

4. Infrastructure – This Infrastructure project is where the dependency inject container modules are placed. This is also where you might place things like Automapper, Logging, and the like. The idea is that these things are configurable things that the entire application would potentially use.

   1. IoC Modules – IoC modules are DI container for specific areas of the architecture.
   2. Data – Data only interface to class mappings
   3. Domain – Domain only interface to class mappings

5. Services – This project represents the REST services that clients could use to access the core domain logic in the application and data behind the applications logic.

   1. Controllers – For each aggregate root in the domain you would potentially have a controller that represents the clients’ ability to work with that domain.

6. UI – This project represents the MVC client application that the user would interact with. This is where the look & feel and usability would be.

   1. Controllers – For each aggregate root in the domain you would potentially have a controller that would communicate to the service layer where an end-point would exists for that domain root.

   2. Helpers – This is where you would place any helper that is shared in the UI project. For example you would place the service proxy class here which is an abstraction to getting access to the service controllers.

   3. Scripts – For each view/partial/page in the UI you may need a JavaScript module to handle client/browser specific functionalities. This is where you would place that code. Currently the architecture is set up to support the jQuery Widget Factory.

7. Tests – This is where you would place all of the Unit Tests the application would need to execute to ensure it is in a healthy state.