Exploring the Decoupled Approach

Exploring the Decoupled Approach

In general, a decoupled architecture is a framework for complex work that allows components to remain completely autonomous and unaware of each other.

Lets analzye how to achieve a decoupled approached when designing and building an application.

Through my never ending learning adventure as a developer. I’ve encountered many go to phrases when the topic of decoupled architecture as opposed to soup was put on the table.

IOC , DI , Repository ,Service etc as well as various Design Patterns such as DDD that go with it.What Do These All Mean and Why not just call the database direct?

Model ----> (Fetch Data) Database

This brings us to the ‘first planet’ we explore in this deep decoupled space.

IOC and Dependency Injection

The main goal of inversion control and dependency is to remove dependencies of an application, this makes the system more Decoupled and Maintainable.

IOC is a pattern used to invert the control of dependency by switching to another location which controls are inverted

A High Level module should not depend on a Low Level module and both should depend on an abstraction.

There are three ways to invert control

1. Interface Inversion

2. Flow Inversion

3. Creation Inversion

   okay so lets look at the flying to Pluto approach- on one tank of fuel again..

   Model ----> (Fetch Data) Database

   Looking at the above we can safely say the model class has a dependency (Opposite of Decoupled) on the Database

   At the root the container is nothing more than a map of dependencies that your class needs with its logic in order to create those dependencies. Injecting dependencies- meaning the dependency is pushed into the class from the outside.

   Pros

   So instead of constructing all your classes yourself you ask the container for a new instance,

   The Container can resolve complex Dependencies transparently so you want to swap out a generic dependency you only need to update the container

   The best part is we already have Nuget package space boosters to get us there even quicker

   Unity :

   

   Ninject :

Injected in the controllers :

Hopefully at this point of our Deep Space Decoupled Exploration Mission we can safely agree that we would surely perish without IOC and DI.

Let’s look at the creating the Backend of our Mothership, this is the Engine that drives our decoupled Deep Space Explorer.

What is the best approach to achieve Light speed Performance?

Hit the Generic Go Booster and let’s explore the Deep Decoupled space with our first approach .

DDD - Domain Driven Design

Proper object oriented code that focuses on the representation of the problem domain through objects.

The Ideal world of DDD is one where your "Application Logic" Domain Model Code is clear of any UI or Persistence Details and its sole purpose and focus is your Problem Domain and Not any display or Persistence details

Service

You can think of services as classes that don’t represent an entity in your application such as a customer or order but represent a process or activity which may or may not correspond to a business process.

My Domain Layer is a Class Library which can contain Services,Precis ,Requests ,Responses etc. Additonally it contains our Service Base Lets Fire those thrusters and explore the Deep Decoupled Space.

We can start our journey at a controller level of a MVC Client

The

new FindUsersAction

Resides in an entire new class library once again called the Shared Action Layer

Reason For this Strategy in my Deep Decoupled Exploration could be

⦁If we had multiple Clients we could use this shared layer for cross cutting concerns

⦁Allow us to Test Small Pieces of Code resulting in more code coverage during Unit Testing

Call the Domain Service Layer with our Request object :

Defined by the following contract :

In Order To Maintain Optimum Velocity through our decoupled approach and be able to define multiple cylinder Services in our Mothership we can define Interfaces which holds the contract to unleashing the light beam thrusters as a fail-safe or as a roll back engage the teleport thrusters.

Define the Interface as follows:

Define your service as the following:

A GenericFindResponse is defined as the following:

Define Your Service Base as the Following:

This is one approach used to create the backend Mothership engine, another approach would be to use...

Generic Repository Pattern

Repository

Persistence code should not be a part of your Domain Model.

You should define repositories that are responsible for all the data needs of an object cluster

All data Access Logic is encapsulated in repositories and your application should not use any other way of accessing the database

Controller is defined as the following:

In this approach we could add a Class Library known as the Data Access Layer

Define the Interface as the following:

Define the Repository as the following:

Define the Interface for our Context:

Define the IocDbContext:

Once again this approach would create the mothership backend but is it enough to explore the Deep Decoupled space and return safely?

The Last Deep Decoupled Approach we could utilize in our mission could be...

Generic Repository with Unit of Work Pattern

Controller can be defined as:

A Engine Part which can make use of all Thrusters and Engine Services Seamlessly is known as the Unit Of Work class it is defined as the following:

As I venture deeper into the unknown depths of the Deep Decoupled Space I still have so many unanswered questions...

If I wanted to create and design that mothership that would take me to Pluto on one Defined Energy Source Swapping out energy Services To get me all the Way there

What is the best Decoupled Approach to Build the Motherships Backend Engine and create optimum performance?

A). Domain Driven Service Design Pattern (Not Even Sure if this is what you call it)?

B). Generic Repository with Unit Of Work Pattern ?

C). Generic Repository Pattern?

Author: Kasheef Kay Albertus

Thank you so much for this opportunity to learn and engage with the top mastermind’s in the software industry it is a real honour being a part of the Stack Overflow Community.