Search code examples
c#design-patternsdependency-injectionsolid-principlesn-tier-architecture

Service Aggregator In N Tier Architecture Pattern

I develop an N Tier Architecture application

You can see at this link

At there I have an question.

As we know that in classic n tier architecture each service layer consist of many public and private class like that I shared below

enter image description here

This structure can be very complex when project begin to grow.

I implement Service Aggregator to fix this problem. According to this idea this service's each public class can be moved to separate class and cs file.

For example in the given example at above ;

I divided each public class to a different .cs file and I used "ITripServiceAggrigator" in controller side.

enter image description here

And I aggregate this services under ServiceAggregator via interfaces and dependency injection like below.

enter image description here

My question is that Is this approach true or false? Can I implement any different structure at there?

Solution

  • This is a bit opinion based, but what stands out to me overall are the following points:

    1. Naming matters. One of the main reasons why we use patterns is to convey meaning and the Aggregator pattern is a microservices pattern that works as an orchestrator, not a coding or an N-Tier pattern. So I lost some time to check if you meant something else, imagine the time lost by others working on the same project.
    2. This is a very valid configuration and it is very often that we work this way in simple projects. Once your orchestrator services start to get bloated, you might want to look into
      • Facade pattern
      • Builder pattern
    3. Try to work with abstractions rather than breaking down into services. If you have payment services, try to extract abstractions and do the orchestration by providing the proper concrete classess.
    4. If things start to get too complicated, consider extracting functionality into different dlls, project etc and adding a DAL layer into it.
    5. If it still remains that way, why not start thinking into another model?
    • Clean architecture is a good if complicated way to go
    • Event driven designs where you classes react to changes could be leveraged instead of orchestration. Check the Observer pattern as well.

    Hope I helped you a bit.