Why Service layer in Clean or Onion or Hexagonal Architecture is a burden
Mosh is no OK with OCH architecture in defintion.
Overhead of Service Layer, if there is not complex application loigc and feature slice is very thin
Little bit application logic or orchestration of calling Domain Logic will go to Repositories or Controllers
Controller will know about the Domain Classes I think.
Mosh Arch == OCH Arch - Service Layer
No Physical Layers Projects, it increases complexity of Code base
Just Logical Layers in Projects, it increases understability.
Layers violatins are detected by Code Reviews
In case of Multiple Clients, we expose the Web API Controllers to expose the functionality,
No need of App. Services for exposing App Functionalitiy to Multiple Clients
Two Layers of Indrections make the Vertical Feature Slice complex, to understand, develop and maintain
Two Phases of Data Mappings make the Vertical Feature Slice complex, to understand, develop and maintain
We should use the Minified-Mosh-Version of OCH architecture.
Only add the services if the feature is fat and need orchestration
If the feature is flat CRUD Operation, do not go for that.
If the feature is fat, we need big Request Processing Pipeline, add componets in the pipeline
If the feature is flat CRUD, then Controller talking to Enitty Repository and Domain objects having little logic inside them is ok, little application logic will live inside the Controller or Repository. It is OK
Extension Methods on DbSet is the replacement of EntityRepsitories
TDD is the solution of spghetti often broken code. We still have to change things at many places, hampers productivity, understandability, hampers teamwork, More Merge Conflicts, Complex deployment, recompilation, re deployment,
1. Services Classes Command and Query Classes
2. Interfaces for Service Classes
3. Request Repose Models for Data Containers (No Interfaces required)
4. Seperate Testing Classes for Services
5. DI Classes, One extra layer of Indirection, to inject Repositories to Services
6. Mapping Code, Extra mapping code that map Domain obj to Request Response Model
7. Managing References for different projects, external referecnes, internel references
Mosh is no OK with OCH architecture in defintion.
Overhead of Service Layer, if there is not complex application loigc and feature slice is very thin
Little bit application logic or orchestration of calling Domain Logic will go to Repositories or Controllers
Controller will know about the Domain Classes I think.
Mosh Arch == OCH Arch - Service Layer
No Physical Layers Projects, it increases complexity of Code base
Just Logical Layers in Projects, it increases understability.
Layers violatins are detected by Code Reviews
In case of Multiple Clients, we expose the Web API Controllers to expose the functionality,
No need of App. Services for exposing App Functionalitiy to Multiple Clients
Two Layers of Indrections make the Vertical Feature Slice complex, to understand, develop and maintain
Two Phases of Data Mappings make the Vertical Feature Slice complex, to understand, develop and maintain
We should use the Minified-Mosh-Version of OCH architecture.
Only add the services if the feature is fat and need orchestration
If the feature is flat CRUD Operation, do not go for that.
If the feature is fat, we need big Request Processing Pipeline, add componets in the pipeline
If the feature is flat CRUD, then Controller talking to Enitty Repository and Domain objects having little logic inside them is ok, little application logic will live inside the Controller or Repository. It is OK
Extension Methods on DbSet is the replacement of EntityRepsitories
TDD is the solution of spghetti often broken code. We still have to change things at many places, hampers productivity, understandability, hampers teamwork, More Merge Conflicts, Complex deployment, recompilation, re deployment,
1. Services Classes Command and Query Classes
2. Interfaces for Service Classes
3. Request Repose Models for Data Containers (No Interfaces required)
4. Seperate Testing Classes for Services
5. DI Classes, One extra layer of Indirection, to inject Repositories to Services
6. Mapping Code, Extra mapping code that map Domain obj to Request Response Model
7. Managing References for different projects, external referecnes, internel references
No comments:
Post a Comment