Skip to content

Framework Architecture

Jump to bottom
John Bales edited this page Nov 8, 2016 · 3 revisions

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.

Developer Workflow

The following describes the workflow that a developer would exercise in working with not only the application framework but also in ensuring that they have the latest code and are committing code changes when it makes most sense. It is assumed that as a developer you understand how to create working folder on your developer machine so that you can pull the code from TFS and open it in Visual Studio to make changes, build and deploy the code locally. The code is structured just as the application architecture describes earlier in this document with the following outline.

  • Core
  • Data
  • Domain
  • Infrastructure
  • Services
  • Tests
  • UI

Beyond that, TFS has the following repositories which have a merge dependency between them. The merge relationship is such that once code is committed to the Development branch, development should be merged into QA. Once the code has been committed for that merge the code for QA can then be merged into the Production branch and then committed.

  • Development
  • QA
  • Production

If there are going to be multi developers working on this application then once one commits code to the development branch the other developer(s) should get the latest before developing any further. This will ensure that everyone on the team has the latest working code and there reduced surprises later.

Clone this wiki locally