Dear all,

I want to start the blog with a bit of a theoretical view on software - I am working in software development since some years now, but there are different reasons for software to work, at a glimpse:

• pure, unfiltered luck
• a dedicated resource keeping it alive
• a clean and structured approach

Let's skip the first two methods and take a look at the latter: not specifying any preferred approach here, but the successful teams always have a common understanding of the underlying architecture before integrating something. In my former days, I often received projects written by other software developers and I was like "how could they do this in that manner?" but the real point here was more like "I do not understand the intention of the structure here fully if even.".

Ingredients

• C# Editor like Visual Studio

Recipe

Having said that, there are common approaches of structuring software to be able to let a "nutless monkey" implement features as long as he understood the approach.

You have like Code Cookbooks, of course the all inspiring "Code Complete" book by Microsoft Press, Design Patterns and all of that. But they don't really tell the full story and the answer to the question

"HOW THE F&%$§! DO I CREATE LAYERS AND STUFF IN MY APPLICATION?!¿"

Now that we are on the philosophical and swearing road, let me show you the model I set up for myself:

The Model

Nothing groundbreaking at all - in the very end, I basically created some logical layers and lots of vertical stuff, probably not even complete.

The Layers contain the following Services / Paradigms:

• Security Layer
  • AuthorizationService
• Messaging Layer
  • MessageService
  • UserNotificationService
• Logging Layer
  • LogService
  • ErrorService
• Application Control Layer
  • ObjectService
  • TimeService
  • TaskService
  • UserService
  • ConfigurationService
  • FeatureService
  • AppService
  • TechnicalService
• User Interface Layer
  • TranslationService
  • UI, of course
• Business Logic Layer
  • ViewModels
  • AIService
  • DirectorService
• Data Access Layer
  • Models
  • PersistanceService

Of course, we could start a detail discussion here around the correct link of each component to each layer but I think the point is rather having a base structure in place which can be followed. If a TranslationService is placed under UI or Logging, that is not too important at the current stage.

The Implementation

Also, how does somebody implement application layers? As we all should know, using global (static) classes and singletons, everything can use everything in modern software development. It just shouldn't 🙂

This implementation proposal is heavily based on dependency injection, as each class can clearly state dependencies (in the c'tor) and the components are easily exchangeable.

Looking back at the model, we can see some services which are linked to some layers. Those services are always interfaces (of course!) with individual implementations. Depending on the position in the Model, they should be dependencies by other services or parts as well.

Fun Fact: with DI, the dependencies are not stated in the Service Interface, but the current implementation - meaning implementation A can have different dependencies than implementation B.

Result

A common understanding of the base application layers and which services belong where. Bonus points are available for using Attributes to enrich the Layer Info to the Services.