A feature can be described as a group of stories that are related and deliver a package of functionality that end users would generally expect to get all at once.

Each library represents a feature that contains a vertical slice of functionality within the application. This means that each library is fully functional from the User interface all the way to the data access layer.



As the architecture continues to get flushed out by features, common code can be identified and consolidated into a shared library. For this shared library, we can call it “Core”.


Feature Composition

Earlier, I had described a basic breakdown of an architectural design. However, each feature library that was identified, tightly coupled the user-interface, model, and the data access layer.

We can now split these responsibilities into their own libraries as follows:


As depicted above, each feature has been broken down into three separate libraries:

  • UI (User Interface)
  • Core (Infrastructure)
  • DAL (Data Access Layer)

By composing a feature into logical layers this way, our solution can now have stronger compliance with the Single Responsibility Principle and as a result, reduce the amount of code that needs to be recompiled in the event that updates are made to the codebase.

We could then focus on the feature itself by setting the scope within Solution Explorer:


We now have complete focus on the feature we’re maintaining as depicted:



In conclusion, I have explained a method of building an architecture. By using this methodology to build a system, we can quickly identify the primary functions of the system without having to drill into folders called “Models”, “Views”, or “Repositories”. As a result, our Solution Explorer is now the blueprint for the system’s architecture.


Scott Nimrod is fascinated with Software Craftsmanship.

He loves responding to feedback and encourages people to share his articles.

He can be reached at scott.nimrod @ bizmonger.net