DEV Community: Khalid BOURZAYQ

Your .NET Application Compiles. Does That Mean Your Architecture Is Correct?

Khalid BOURZAYQ — Fri, 30 Oct 2026 19:47:22 +0000

When we start developing a new application, one of the first things we usually discuss is its architecture.

Should we use Clean Architecture? A modular monolith? A traditional layered architecture?

We define our projects, organize dependencies, establish some rules, and everything looks good.

But what happens after six months? Or after several developers have worked on the same solution?

More importantly, who makes sure that the architecture we initially designed is still respected?

The compiler? Not really.

Our unit tests? Not necessarily.

Code reviews? Maybe, if someone notices the problem.

This is something I've been thinking about for a while, especially with the increasing adoption of AI coding agents.

Let's take a practical example to understand the problem, and then see how we can address it.

When valid C# becomes an architectural problem

Imagine we're developing an order management application using Clean Architecture.

Our solution contains the following projects:

Shop.slnx
│
├── Shop.Domain
│   ├── Order.cs
│   └── IOrderRepository.cs
│
├── Shop.Application
│   └── OrderService.cs
│
├── Shop.Infrastructure
│   └── SqlOrderRepository.cs
│
└── Shop.Api
    └── Program.cs

Nothing complicated here.

The Domain layer contains our business model and abstractions.

Application contains the use cases.

Infrastructure contains the technical implementations.

And API is our entry point and composition root.

According to the Dependency Rule, dependencies should point inward. Domain should not know about Infrastructure, and Application should not directly depend on Infrastructure implementations.

Now, imagine that we're implementing a use case to confirm an order.

A developer writes the following code:

using Shop.Domain;
using Shop.Infrastructure;

namespace Shop.Application;

public sealed class OrderService(
    SqlOrderRepository repository)
{
    public async Task ConfirmAsync(
        Guid orderId,
        CancellationToken cancellationToken)
    {
        var order = await repository.GetAsync(
            orderId,
            cancellationToken);

        order.Confirm();

        await repository.SaveAsync(
            order,
            cancellationToken);
    }
}

Assuming the project reference exists and the repository exposes these methods, this code is perfectly valid from the compiler's perspective.

It can compile successfully.

The unit tests can pass.

The feature can work exactly as expected.

So, what's the problem?

Well, our Application layer now directly depends on Infrastructure.

We have introduced an outward dependency that violates the architecture we initially agreed on.

And this is where things become interesting.

The compiler checks whether our code is valid C#. It doesn't know whether the dependencies respect our architectural decisions.

Of course, we could catch this during code review. But should we really depend entirely on code reviews to detect something that can be checked automatically?

I don't think so.

Let's refactor our code

The problem is not the functionality itself. The problem is the dependency.

Instead of injecting SqlOrderRepository, our Application layer should depend on an abstraction.

Let's start with our Domain project.

namespace Shop.Domain;

public interface IOrderRepository
{
    Task<Order> GetAsync(
        Guid id,
        CancellationToken cancellationToken);

    Task SaveAsync(
        Order order,
        CancellationToken cancellationToken);
}

We can now change our Application service:

using Shop.Domain;

namespace Shop.Application;

public sealed class OrderService(
    IOrderRepository repository)
{
    public async Task ConfirmAsync(
        Guid orderId,
        CancellationToken cancellationToken)
    {
        var order = await repository.GetAsync(
            orderId,
            cancellationToken);

        order.Confirm();

        await repository.SaveAsync(
            order,
            cancellationToken);
    }
}

And let Infrastructure implement the abstraction:

using Shop.Domain;

namespace Shop.Infrastructure;

public sealed class SqlOrderRepository
    : IOrderRepository
{
    // Persistence implementation
}

Finally, we register the implementation in our API project:

builder.Services.AddScoped<
    IOrderRepository,
    SqlOrderRepository>();

There it is!

Our Application layer no longer depends on Infrastructure.

We have restored the intended dependency direction.

But we haven't solved the original problem yet.

What prevents another developer from introducing the same violation tomorrow?

Nothing, unless we introduce a mechanism to enforce that boundary.

What if architectural rules were executable?

We already automate a lot of things in software development.

We use analyzers to enforce coding conventions, tests to validate behavior, and CI pipelines to verify our changes before merging.

Why shouldn't we do the same with architecture?

Imagine being able to declare the following rules:

Application can depend on Domain.
Infrastructure can depend on Domain.
Domain cannot depend on Application or Infrastructure.
Modules can only access another module's explicitly exposed contracts.

And then automatically validate those rules against our solution.

This is the idea behind Architecture Guardian, an open-source .NET tool I've been working on.

It allows us to describe architectural boundaries using a YAML policy and validate them through Roslyn analyzers, a CLI, and MCP tools for AI coding agents.

Let's see how it works.

Defining our architecture

Instead of keeping our architecture rules only in documentation, we'll describe them in a file called architecture.guardian.yaml.

For our Shop solution, the policy can look like this:

version: 1

modules:
  - id: Shop
    projects: ["Shop.*/*.csproj"]

layers:
  - id: Domain
    projects: ["Shop.Domain/*.csproj"]

  - id: Application
    projects: ["Shop.Application/*.csproj"]
    allowedDependencies: [Domain]

  - id: Infrastructure
    projects: ["Shop.Infrastructure/*.csproj"]
    allowedDependencies: [Domain]

  - id: Api
    projects: ["Shop.Api/*.csproj"]
    allowedDependencies:
      - Domain
      - Application
      - Infrastructure

rules:
  AG002: error
  AG003: error

gate:
  failOn: error

Here, each project belongs to a layer, and each layer has an explicit list of allowed dependencies.

Notice that Application can only depend on Domain.

So, if someone introduces a dependency from Application to Infrastructure, it will violate our policy.

The important point is that Architecture Guardian doesn't impose Clean Architecture on your application.

You define your architecture. The tool verifies whether your code respects it.

For example, if we were using a different architectural style, we could define different boundaries and permissions.

The policy should describe the architecture we've chosen, not an architecture selected by the tool.

Let's break our architecture again

Remember our first implementation of OrderService?

Let's introduce the same problem again.

using Shop.Infrastructure;

namespace Shop.Application;

public sealed class OrderService(
    SqlOrderRepository repository)
{
    // ...
}

And suppose we add the corresponding project reference.

Our application can still compile.

But now we can validate the architecture.

First, install the Architecture Guardian CLI:

dotnet tool install --global \
  ArchitectureGuardian.Cli \
  --version 0.3.0

After restoring the solution, we can run:

archguard scan Shop.slnx \
  --policy architecture.guardian.yaml \
  --configuration Release \
  --trusted

For a repository we've authorized for MSBuild evaluation, --trusted allows the scan to proceed. It doesn't isolate untrusted build logic.

The scan can now detect our forbidden dependency and report an AG002 error.

An example diagnostic looks like this:

Shop.Application/OrderService.cs:
error AG002:
Layer 'Application' must not depend on
layer 'Infrastructure'.

Our code still compiles.

But our architecture validation fails.

That's exactly what we wanted.

Instead of depending on someone noticing an architectural violation during a pull request, we now have an explicit rule that can be checked automatically.

What about a modular monolith?

So far, we've looked at a fairly simple layered architecture.

Let's take a slightly more interesting case.

Imagine we're developing a modular monolith containing three business modules:

src/
├── Catalog/
│   ├── Catalog.Domain/
│   ├── Catalog.Application/
│   ├── Catalog.Contracts/
│   └── Catalog.Infrastructure/
│
├── Orders/
│   ├── Orders.Domain/
│   ├── Orders.Application/
│   └── Orders.Infrastructure/
│
└── Billing/
    ├── Billing.Contracts/
    ├── Billing.Application/
    └── Billing.Infrastructure/

Orders needs to retrieve some product information from Catalog.

A developer finds the following class:

namespace Catalog.Infrastructure;

public sealed class ProductRepository
{
    public Task<Product> GetAsync(Guid id)
    {
        // ...
    }
}

Since the class is public, the developer decides to inject it into Orders:

using Catalog.Infrastructure;

namespace Orders.Application;

public sealed class CreateOrderHandler(
    ProductRepository products)
{
    // ...
}

Again, the code can compile if the required references exist.

But we've introduced another problem.

Orders now knows about Catalog's internal persistence implementation.

What happens if Catalog changes its storage technology?

What if we replace SQL Server with another persistence mechanism?

Why should Orders care about that?

It shouldn't.

This is an example of an implementation detail leaking across module boundaries.

Refactoring through a public contract

Let's expose an abstraction through Catalog.Contracts.

namespace Catalog.Contracts;

public interface IProductReader
{
    Task<ProductDto?> GetAsync(
        Guid productId,
        CancellationToken cancellationToken);
}

Now, Orders only depends on the contract:

using Catalog.Contracts;

namespace Orders.Application;

public sealed class CreateOrderHandler(
    IProductReader products)
{
    // ...
}

Catalog can implement this interface internally.

Orders doesn't need to know whether the data comes from Entity Framework Core, an HTTP service, or something else.

We've created an explicit module boundary.

Architecture Guardian provides two complementary checks for this scenario:

AG001 validates whether a dependency between modules is allowed.

AG004 detects cross-module access to implementation projects instead of declared public contracts.

One important detail: a class being marked public in C# doesn't automatically make it a public architectural contract.

That distinction is particularly important in modular monoliths.

When the problem is bigger than one project

Now let's look at another interesting case.

Imagine we have two modules, Orders and Billing.

Orders needs some information from Billing, and Billing also needs some information from Orders.

Each module exposes its own Contracts project.

The dependencies look like this:

Orders.Application
    depends on Billing.Contracts

Billing.Application
    depends on Orders.Contracts

There is no circular project reference here.

The solution can build successfully because the contract projects don't reference each other.

However, at the logical module level, we have created a cycle.

Orders depends on Billing, and Billing depends on Orders.

Is this always a catastrophic problem?

Not necessarily. But if our architectural goal is to keep modules independent and prevent cycles, we need to detect it.

This is what AG003 is designed for.

It identifies cycles between logical modules using a complete solution analysis.

And this brings us to an important distinction between Roslyn analyzers and solution-level architecture checks.

Why Roslyn analyzers are not enough

Roslyn analyzers are extremely useful because they give us feedback directly while coding.

Architecture Guardian includes a Roslyn analyzer that can detect supported architectural violations within the compilation being analyzed.

This is valuable for developers because they don't have to run a separate command every time they modify a dependency.

But a Roslyn analyzer doesn't have the complete view of every relationship in a solution.

For example, the logical module cycle we just discussed requires examining dependencies across multiple projects.

That's why Architecture Guardian also provides a solution scanner.

The responsibilities are different:

Roslyn analyzer: immediate feedback for supported rules within the current compilation.
CLI: full solution analysis, including logical module cycles, with a gate suitable for automation.
MCP server: architectural context and analysis tools for AI coding agents.

The analyzer currently covers AG001, AG002, and AG004 through AG006 within its compilation scope.

AG003 requires the solution scan.

So, having no diagnostics in the editor is useful, but it doesn't mean the entire solution is architecturally compliant.

Enforcing the rules in CI

Now that we have defined our architecture, there's one more thing we should do.

Make sure that no change can be merged without validating it.

Since Architecture Guardian provides a CLI, we can execute the scan in an Azure DevOps pipeline, GitHub Actions workflow, or another CI environment.

For example:

steps:
  - script: |
      dotnet restore Shop.slnx \
        -p:Configuration=Release
    displayName: Restore solution

  - script: |
      archguard scan Shop.slnx \
        --policy architecture.guardian.yaml \
        --configuration Release \
        --trusted
    displayName: Validate architecture

This example assumes the agent already has the CLI and a compatible .NET SDK installed, and that the repository is trusted.

The scanner returns different exit codes depending on the result.

A successful scan passes the gate.

An architectural violation can fail the pipeline.

And if analysis cannot establish compliance, that is reported separately rather than being considered a successful architecture check.

This distinction is important.

A tool that couldn't analyze your solution shouldn't tell you that your architecture is valid.

For existing applications, Architecture Guardian also supports baselines and change-oriented analysis, which can help teams introduce enforcement progressively instead of fixing every historical violation immediately.

And what about AI coding agents?

This is probably one of the most interesting parts of the project for me.

We're increasingly using AI coding agents to implement features, refactor code, and work across entire repositories.

They can generate quite impressive code.

But they can also introduce architectural violations.

Let's return to our modular monolith.

Imagine giving an agent the following task:

"Implement a feature in Orders that retrieves product information from Catalog."

The agent explores the codebase and discovers Catalog.Infrastructure.ProductRepository.

The class is public.

The method already does what the agent needs.

So, it adds the reference and implements the feature.

The result can be functional.

But the agent has completely bypassed the architectural contract we wanted to preserve.

Was the agent wrong?

From a functional perspective, perhaps not.

From an architectural perspective, yes.

The problem is that the agent may not know our architectural decisions, especially when those decisions are only documented in a README or an architecture diagram.

Giving agents architectural context

Architecture Guardian provides an MCP server that exposes architectural information to compatible AI coding agents.

Instead of simply asking an agent to respect Clean Architecture, we can give it tools to inspect the actual architectural policy.

The MCP integration exposes operations such as:

get_architecture to discover modules, layers, and dependency permissions.
list_rules to understand available rules.
analyze_solution to validate changes against the solution.
explain_violation to understand a reported problem and its possible remediation.
analyze_changes to inspect findings relative to Git changes.

Let's imagine a different workflow.

Before implementing the feature, the agent asks Architecture Guardian for the solution's architectural context.

It discovers that Orders is allowed to access Catalog through its contract project, but not through Infrastructure.

The agent implements the feature using IProductReader.

Then it runs the architecture analysis.

If a violation is reported, it can inspect the diagnostic and correct its implementation.

The difference is that the agent no longer has to rely only on natural-language instructions to understand our architectural boundaries.

It can query them.

Of course, MCP doesn't guarantee that an agent will always make the right architectural decision.

And it doesn't replace the CI gate.

But it gives agents access to the same architecture policy that developers and pipelines use.

This is the direction I wanted to explore with Architecture Guardian.

Does this replace architecture tests or code reviews?

No, and I think it's important to clarify this.

We already have libraries and approaches for writing architecture tests in .NET.

They're useful, and Architecture Guardian isn't intended to make them irrelevant.

The goal is to make architectural rules available throughout the development workflow, instead of limiting validation to tests that someone must remember to run.

It also doesn't replace code reviews.

An architectural rule can verify that Application doesn't depend on Infrastructure.

But it cannot decide whether your abstraction is well designed, whether your aggregates make sense, or whether you've selected the appropriate architecture for your business requirements.

Those decisions still require engineering judgment.

The tool is there to enforce the boundaries we've explicitly declared.

And we should be careful not to create unnecessary restrictions.

The goal is to protect our architecture, not to make development more complicated.

Let's try it

Architecture Guardian is available on GitHub and distributed through NuGet.

You can start by installing the CLI:

dotnet tool install --global \
  ArchitectureGuardian.Cli \
  --version 0.3.0

Create your architecture.guardian.yaml policy, restore the solution, and run the scanner.

There is also a runnable Clean Architecture example in the documentation, containing both compliant and intentionally violating configurations.

You can experiment with different dependency violations and observe the diagnostics without modifying your own application.

If you want to integrate the checks into your IDE, the Roslyn analyzer package is also available.

And if you're experimenting with AI coding agents, you can explore the MCP integration.

The full setup instructions and examples are available here:

Documentation: https://kbourzayq.github.io/arch-guard/

GitHub: https://github.com/kbourzayq/arch-guard

Final Thoughts

To conclude, I think we sometimes spend a lot of effort designing software architectures without putting the same effort into preserving them.

We discuss dependency rules, module boundaries, separation of concerns, and all the principles that should help us build maintainable software.

But as the application grows, it's surprisingly easy to introduce dependencies that contradict those decisions.

And most of the time, the compiler won't complain.

My intention with Architecture Guardian is not to introduce another architectural framework or tell developers how they should design their applications.

It's to provide a way to define architectural decisions once and continuously verify them.

A last piece of advice: don't try to enforce every possible architectural rule from the first day, especially if you're working on a large existing application.

Start with the boundaries that matter most, understand your existing dependencies, and progressively introduce stricter validation.

Otherwise, the tool intended to protect your architecture might become an unnecessary obstacle for your team.

That's it!

Architecture Guardian is open source, and feedback is more than welcome.

I'm particularly interested in hearing how other teams manage architectural boundaries in large .NET solutions, modular monoliths, and AI-assisted development workflows.

Feel free to try it, challenge the approach, open an issue, or contribute.

See you soon!

References

SRP - Is the most misunderstood principle ?

Khalid BOURZAYQ — Tue, 15 Mar 2022 11:59:58 +0000

Definition

Defined by Robert C. Martin, it’s the first of the five design principles SOLID.

what he said may seem very simple to us

A class should have only one reason to change

However, implementing this simplicity can be complicated.

And because of the confusion around the word "reason", he also stated

This principle is about people

What he means by people is the people who use our system or in other words the actors.

Actors become the source of change for the family of features that serve them.

As their needs change, that specific family must also change to meet their needs.

Uncle bob gave a funny example in The Single Responsibility Principle The Clean Code Blog

Imagine you took your car to a mechanic in order to fix a broken electric window. He calls you the next day saying it’s all fixed. When you pick up your car, you find the window works fine; but the car won’t start. It’s not likely you will return to that mechanic because he’s clearly an idiot.

That’s how customers and managers feel when we break things they care about that they did not ask us to change.

SRP is probably not what do you think it is. If you think that "A class should do only one thing and do it well", this is not the correct explanation of the principle (it's partially correct) and in the same time it's the most commun.

Yeah, this is the common misunderstanding of the principle.

Uncle Bob provides a more clear explanation in his book
"Clean Architecture: A Craftsman's Guide to Software Structure and Design" to further explain its intention in this principle.

A module should be responsible to one, and only one, actor

So, let's go on and see how we can apply SRP in practice.

Code refactoring example

Taking the following example, we have a product class where we find a set of methods:

A method to save the product in a txt file
A method that generates a report file.
Two other methods to manage or validate the data according to the management rules before changing the value of the field.

public class Product
{
    public string Label { get; set; }
    public string Description { get; private set; }
    public double Price { get; private set; }

    private readonly StringBuilder _priceActions = new();

    public Product(string description, string label, double price)
    {
        Label = label;
        ChangeDescription(description);
        ChangePrice(price);
    }

    public void ChangePrice(double price)
    {
        if (price == 0)
        {
            Console.WriteLine("price can't be zero!");
            throw new ArgumentNullException(nameof(price));
        } if (price < Price)
            _priceActions.Append($"New price applied to the product : ' {Label} '" +
                                 $". \n Old price {Price} " +
                                 $"\n New Price is {price}");
        Price = price;
    }

    public void ChangeDescription(string desc)
    {
        if (string.IsNullOrWhiteSpace(desc))
        {
            Console.WriteLine("description can't be null");
            throw new ArgumentNullException(nameof(desc));
        }
        Description = desc;
    }

    public void Save()
    {
        var fs = new FileStream("products.txt", FileMode.Append, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine($"Label:{Label},Description:{Description},Price:{Price}");
        writer.Close();
        fs.Close();
    }

    public void GenerateReportFile()
    {
        var fs = new FileStream("report.txt", FileMode.Create, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine("****this is a report****");
        writer.WriteLine("product basic infos");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine($"{Label} - {Price}");
        writer.WriteLine($"Description : {Description}");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine("price actions");
        writer.WriteLine($"{_priceActions}");
        writer.Close();
        fs.Close();
    }
}

If we think of the actors involved in the use of the product object, who could they be?

We can easily from these methods identify the following actors and reasons:

An editor who manages the basic information of the product.
Top management people for product reporting reasons.
The persistence way or the storage system.

Doing this kind of analysis, we can easily identify that the methods that we must have outside of the product class are the following:

Reporting method and related code stuff.
Storage method.
Validation rules and related messages.

So, let's refactor our code to follow SRP.

Let's start with the storage.

In this step, we will extract the method save into a new class which will be only responsible for storage stuff.
So, the related code in this class will change only if the storage manner change.

public interface IProductRepository
{
    void Save(Product product);
}

public class ProductRepository : IProductRepository
{
    public void Save(Product product)
    {
        var fs = new FileStream("products.txt", FileMode.Append, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine($"Label:{product.Label},Description:{product.Description},Price:{product.Price}");
        writer.Close();
        fs.Close();
    }
}

We will continue our refactoring by extracting all validation rules and business validation messages into classes that will be the single entry point for every change in our business rules.

We will refactor the code in this way:

First, we will extract the validation rules into a class that will be responsible only for product validations.
Second, all the messages will be in a single class which will represents the single entry point for our business validation messages.
In the final step, we will add a custom exception class for throwing all product business exception if something went wrong.

public class ProductBusinessException : Exception
{
    public ProductBusinessException(string message) : base(message)
    {
    }
}

public static class BusinessExceptionMessages
{
    public const string PriceIsnullErrorMessage = "price can't be zero!";
    public const string DescriptionIsnullErrorMessage = "description can't be null";
}

public class ProductValidator
{
    public static void ValidatePrice(double price)
    {
        if (price == 0)
            throw new ProductBusinessException(BusinessExceptionMessages.PriceIsnullErrorMessage);
    }

    public static void ValidateDescription(string description)
    {
        if (string.IsNullOrWhiteSpace(description))
            throw new ProductBusinessException(BusinessExceptionMessages.DescriptionIsnullErrorMessage);
    }
}

In the final step, we will refactor all the code related to the reporting stuff.

So, we will extract the method GenerateReportFile into a new class.
and we will add a new method to our product class in order to expose all the price changes related to the product.

    //New method in our product class 
    public string GetPriceChanges()
    {
        return _priceActions.ToString();
    }

public interface IProductTextReporting
{
    void GenerateReportFile(Product product);
}

public class ProductTextReporting : IProductTextReporting
{
    public void GenerateReportFile(Product product)
    {
        var fs = new FileStream("report.txt", FileMode.Create, FileAccess.Write);
        var writer = new StreamWriter(fs);
        writer.WriteLine("****this is a report****");
        writer.WriteLine("product basic infos");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine($"{product.Label} - {product.Price}");
        writer.WriteLine($"Description : {product.Description}");
        writer.WriteLine("-----------------------------------");
        writer.WriteLine("price actions");
        writer.WriteLine($"{product.GetPriceChanges()}");
        writer.Close();
        fs.Close();
    }
}

After the refactoring, our product class looks like the code below.

public class Product
{
    public string Label { get; set; }
    public string Description { get; private set; }
    public double Price { get; private set; }

    private readonly StringBuilder _priceActions = new();

    public Product(string description, string label, double price)
    {
        Label = label;
        ChangeDescription(description);
        ChangePrice(price);
    }

    public void ChangePrice(double price)
    {
        ProductValidator.ValidatePrice(price);
        if (price < Price)
            _priceActions.Append($"New price applied to the product : ' {Label} '" +
                                 $". \n Old price {Price} " +
                                 $"\n New Price is {price}");
        Price = price;
    }

    public void ChangeDescription(string desc)
    {
        ProductValidator.ValidateDescription(desc);
        Description = desc;
    }

    public string GetPriceChanges()
    {
        return _priceActions.ToString();
    }
}

There it is ! we have refactored our code in a way that each class will have only one reason to change.

Final Thoughts

To conclude, once you find that a class or module starts to change for different reasons, take the time and effort to refactor your code to follow SRP, but needless refactoring can bring us down to classes or modules that are difficult to understand.

A second advice, if you are working in a high coupled software, module or class, be careful when you are refactoring your code, take you time in order to uncouple it before, because any fast refactoring step can lead you to a disaster.

That's it !
Ask me, comment below, share it, rate it, whatever you want.
See you soon.

References

Source code : Link to github with the whole code from this article
The Clean Code Blog : The Single Responsibility Principle
Clean Architecture: A Craftsman's Guide to Software Structure and Design

Be cautious when implementing the Open Closed Principle

Khalid BOURZAYQ — Thu, 10 Feb 2022 21:29:01 +0000

Caution

Without a clear understanding of polymorphism and composition, OCP and the rest of the principles of SOLID won't make much sense.

Overview Of OCP

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

What does this mean?

It means that your code should be written in a way that leaves it flexible to adapt to changes (Open), without modifying the code already written (Closed).

A simple use case: Filtering Customers by criteria

We have a user story in our application backlog which demand to us to retrieve all the required information about our customers stored in the database, based on different criteria.
So, let’s start with that:

    public enum CustomerType
    {
        UnRanked,
        Silver,
        Glod,
        Platinium
    }

And we have the Customer domain class

    public class Customer
    {
        public string Name { get; set; }
        public string LastName { get; set; }
        public string Address { get; set; }
        public CustomerType Type { get; set; }
    }

Now, we need to implement our filtering functionality. For example, we want to filter by Customer types:

    public class CustomersFilter
    {
        public List<Customer> FilterByType(IEnumerable<Customer> customers, CustomerType type) =>
                customers.Where(m => m.Type == type).ToList();
    }

public List<Customer> GetSilverCustomers()
{
    var customers = new List<Customer>
    {
       new Customer { Name = "C1", Type = CustomerType.Silver},
       new Customer { Name = "C2", Type = CustomerType.Silver},
       new Customer { Name = "C3", Type = CustomerType.Glod}
    };
    CustomersFilter customersFilter = new CustomersFilter();
    var result = customersFilter.FilterByType(customers, CustomerType.Silver);

    return result;
}

The user story is ok, validated and the code goes on production. After a couple of days, we receive a new user story in which the product owner wants to have a filter by subscription as well in the application.

What should we do in this case?

It should be easy, right?
We are going to add a second filter method by subscription and it will work perfectly.

Let's add the subscription enum

    public enum SubscribtionType
    {
        Free,
        Basic,
        Pro,
        Enterprise
    }

And now, we can add our new method in the CustomerFilter class

public class CustomersFilter
{
    public List<Customer> FilterByType(IEnumerable<Customer> customers, CustomerType type) =>
            customers.Where(m => m.Type == type).ToList();

    public List<Customer> FilterByScreen(IEnumerable<Customer> customers, SubscribtionType subscribtion) =>
        customers.Where(m => m.Subscribtion == subscribtion).ToList();
}

By testing the code that we have just added, everything works as it should, on the other hand we have just violated the OCP principle here because we have modified in the class instead of extending it.

Another problem here is that once a new filter is going to be expressed as a need, another filter method must be added.

So, what should we do in such cases?

There are several possible solutions, so that our code respects the OCP principle.
Solution 1: Use inheritance or interface implementation.
In the code below we are using interface implementation.

public interface IFilter<T, E> where T : class where E : Enum
{
    List<T> Apply(IEnumerable<T> collection, E type);
}

public class FilterBySubscibtion : IFilter<Customer, SubscribtionType>
{
    public List<Customer> Apply(IEnumerable<Customer> collection, SubscribtionType type)
    {
        return collection.Where(m => m.Subscribtion == type).ToList();
    }
}

public class FilterByCustomerType : IFilter<Customer, CustomerType>
{
    public List<Customer> Apply(IEnumerable<Customer> collection, CustomerType type)
    {
        return collection.Where(m => m.Type == type).ToList();
    }
}

And our calls will be like:

private List<Customer> customers { get; set; } = new List<Customer>
{
    new Customer { Name = "C1", Type = CustomerType.Silver, Subscribtion = SubscribtionType.Free},
    new Customer { Name = "C2", Type = CustomerType.Silver , Subscribtion = SubscribtionType.Basic},
    new Customer { Name = "C3", Type = CustomerType.Glod, Subscribtion = SubscribtionType.Basic}
};
public List<Customer> FilterCustomers(CustomerType customerType)
{
    IFilter<Customer, CustomerType> customersFilter = new FilterByCustomerType();
    var result = customersFilter.Apply(customers, customerType);
    return result;
}

public List<Customer> FilterCustomers(SubscribtionType subscribtion)
{
    IFilter<Customer, SubscribtionType> customersFilter = new FilterBySubscibtion();
    var result = customersFilter.Apply(customers, subscribtion);
    return result;
}

public List<Customer> GetSilverCustomers() => FilterCustomers(CustomerType.Silver);

public List<Customer> GetCustomersWithFreeSubscibtion() => FilterCustomers(SubscribtionType.Free);

As you can see in the code, we have set up two different implementations per filter type (subscription and customer type).
We also have two methods that call these two filters but we have redundancy in the code.

To avoid this kind of redundance, we will try to make a second implementation based on the specification design pattern.

Solution 2: Use specification pattern

In computer programming, the specification pattern is a particular
software design pattern, whereby business rules can be recombined by
chaining the business rules together using boolean logic. The pattern
is frequently used in the context of domain-driven design.

Source: Wikipedia - Specification pattern

The specification design model allows us to check if an object meets certain requirements (usually functional)
So, with this design pattern, we can reuse specs and combine them when needed.

Let's create our specifications:

public interface ISpecification<T>
{
    bool IsSatisfied(T item);
}

public class CustomerTypeSpecification : ISpecification<Customer>
{
    private readonly CustomerType _type;
    public CustomerTypeSpecification(CustomerType type)
    {
        _type = type;
    }
    public bool IsSatisfied(Customer item) => item.Type == _type;
}

public class SubscribtionTypeSpecification : ISpecification<Customer>
{
    private readonly SubscribtionType _type;
    public SubscribtionTypeSpecification(SubscribtionType type)
    {
        _type = type;
    }
    public bool IsSatisfied(Customer item) => item.Subscribtion == _type;
}

With the ISpecification interface, we can determine whether or not our criteria are met, and then we can send it to the Apply method from the IFilter interface.

Now, time to update our existing code to use these specifications:

    public interface IFilter<T> where T : class
    {
        List<T> Apply(IEnumerable<T> collection, ISpecification<T> specification);
    }

    public class CustomersFilter : IFilter<Customer>
    {
        public List<Customer> Apply(IEnumerable<Customer> collection, ISpecification<Customer> specification)
        {
            return collection.Where(m => specification.IsSatisfied(m)).ToList();
        }
    }

After updating the filter class, let's go to our finale class that use it and make some updates.

public class FilterService
{
    private readonly IFilter<Customer> _filter;

    private List<Customer> customers { get; set; } = new List<Customer>
    {
        new Customer { Name = "C1", Type = CustomerType.Silver, Subscribtion = SubscribtionType.Free},
        new Customer { Name = "C2", Type = CustomerType.Silver , Subscribtion = SubscribtionType.Basic},
        new Customer { Name = "C3", Type = CustomerType.Glod, Subscribtion = SubscribtionType.Basic}
    };
    public FilterService(IFilter<Customer> customerFilter)
    {
        _filter = customerFilter;
    }
    public List<Customer> FilterCustomers(ISpecification<Customer> specification)
    {
        return _filter.Apply(customers, specification);
    }

    public List<Customer> GetSilverCustomers() => FilterCustomers(new CustomerTypeSpecification(CustomerType.Silver));

    public List<Customer> GetCustomersWithFreeSubscibtion() => FilterCustomers(new SubscribtionTypeSpecification(SubscribtionType.Free));
}

As we can see we don’t have any code redundancy in our FilterService class.

Conclusion

We have just seen how OCP can help us create clean and maintainable code. But we must be careful when implementing this principle.

As we saw in our example, this wasn’t an efficient way to use class inheritance. But we shouldn't be afraid to do so, it's completely normal, but we should at least make these changes as discrete as possible.

In other cases, we will be led to use composition over inheritance and use a design pattern such as Strategy to achieve our goal.

To conclude, the idea of this article is to keep OCP in mind during our development and write extensible code as much as possible, because this leads to a maintainable, scalable and testable code base however how the implementation used.

Some useful links:
https://ardalis.github.io/Specification/
https://deviq.com/principles/open-closed-principle

Extended Property Patterns in C# 10

Khalid BOURZAYQ — Wed, 02 Feb 2022 18:33:55 +0000

What does it mean?

Basically, in C# 8.0 Microsoft has introduced the new pattern: Property pattern.

A property pattern matches an expression when an expression result is not null and every nested pattern matches the corresponding property or field of the expression result.

In C# 10, you can reference nested properties or fields within a property pattern.

Example

The following code sample shows a C# Customer class , which contains some properties and a nested property named Address which is in itself an object.


    public class Customer
    {
        public string Name { get; set; }
        public string LastName { get; set; }
        public Address Address { get; set; }

    }
    public class Address
    {
        public string City { get; set; }
        public string ZipCode { get; set; }

    }

    public class DiscountCalculator
    {
        public double GetDiscount(Customer customer)
        {
            if (customer is { Address : { City: "NYC" } })
            {
                return 0.8;
            }
            else
            {
                return 0.9;
            }
        }
    }

As you can see in our GetDiscount method, the syntax for accessing the address nested property is verbose


 if (customer is { FullAddress : { City: "NYC" } })

In C# 10, it’s much more practical, you can reference nested properties or fields within a property pattern.


if (customer is { FullAddress.City: "NYC" })

That's it, for more details about the Extended property patterns
you can refer to the link below:
Extended property patterns

A Quick view of Cached Repository Pattern

Khalid BOURZAYQ — Mon, 31 Jan 2022 14:15:26 +0000

In this article, we will see how to use the Cached Repository pattern with asp.net core web api and entity framework core.

The idea

In this exemple we will create an aspnet core webapi that fetches a list of cutomers stored in the database and the result will be a Data transfert object (DTO) that contains the list of customers and the time taken to fetch the data.

The database will be initialized with 10000 record for testing.

You can find the full source code of this sample in the link below:
https://github.com/kbourzayq/CachedRepository

The Repository Class before Applying cache

The repository class looks like :

public class CustomerRepository : IReadOnlyRepository<Customer>
{
    private readonly AppDbContext _context;

    public CustomerRepository(AppDbContext context)
    {
        _context = context;
    }

    public Customer GetById(int id)
    {
        return _context.Cutomers.First(x => x.Id == id);
    }

    public List<Customer> List()
    {
        return _context.Cutomers.Take(1000).ToList();
    }
}

The Api Controller class :

[Route("api/[controller]")]
[ApiController]
public class CustomerController : ControllerBase
{
    private readonly IReadOnlyRepository<Customer> _repository;

    public CustomerController(IReadOnlyRepository<Customer> repository)
    {
        _repository = repository;
    }
    [HttpGet]
    public ActionResult<CustomerListDto> GetAll()
    {
        var timer = Stopwatch.StartNew();
        var customers = _repository.List();
        timer.Stop();
        CustomerListDto customerList = new CustomerListDto { 
            Customers = customers, 
            ElapsedTimeMilliseconds = timer.ElapsedMilliseconds
        };
        return Ok(customerList);
    }
}

Time to inject dependencies and lunch our app:


Builder.Services.AddScoped<IReadOnlyRepository<Customer>, CustomerRepository>();

As you can see the loading of 1000 records takes some time...

{
  "elapsedTimeMilliseconds": 1226,
  "customers": [
    {
      "name": "Customer 0",
      "lastName": "Customer Lastname 0",
      "address": "Address 0",
      "id": 1
    },
    {
      "name": "Customer 1",
      "lastName": "Customer Lastname 1",
      "address": "Address 1",
      "id": 2
    },
    {
      "name": "Customer 2",
      "lastName": "Customer Lastname 2",
      "address": "Address 2",
      "id": 3
    },
    ....

Let's apply cache

In this example, we want to add caching behavior without modifying the existing code.
In other words, we should add caching to the application without touching any code in the repository implementation shown above or the webapi that uses it.
See: Open closed principle.
To do that, we will use the Decorator pattern.
The Decorator pattern is used to add some behaviors to an existing type without affecting the behavior of other types.

The Cached Repository class looks like the code below :

public class CachedCustomerRepository : IReadOnlyRepository<Customer>
{
    private readonly CustomerRepository _repository;
    private readonly IMemoryCache _cache;
    private const string CustomersCacheKey = "Sample::Customers";
    private MemoryCacheEntryOptions cacheOptions;


    public CachedCustomerRepository(CustomerRepository repository,
        IMemoryCache cache)
    {
        _repository = repository;
        _cache = cache;
        cacheOptions = new MemoryCacheEntryOptions()
            .SetAbsoluteExpiration(relative: TimeSpan.FromSeconds(20));
    }

    public Customer GetById(int id)
    {
        string key = CustomersCacheKey + "-" + id;

        return _cache.GetOrCreate(key, entry =>
        {
            entry.SetOptions(cacheOptions);
            return _repository.GetById(id);
        });
    }

    public List<Customer> List()
    {
        return _cache.GetOrCreate(CustomersCacheKey, entry =>
        {
            entry.SetOptions(cacheOptions);
            return _repository.List();
        });
    }
}

The next setp is to change the injected dependencies :

Builder.Services.AddScoped<IReadOnlyRepository<Customer>, CachedCustomerRepository>();
Builder.Services.AddScoped<CustomerRepository>();
Builder.Services.AddSingleton<IMemoryCache, MemoryCache>();

Now, after implementing our cache, we will launch our application and see what it will give us

First call :

{
  "elapsedTimeMilliseconds": 1224,
  "customers": [
    {
      "name": "Customer 0",
      "lastName": "Customer Lastname 0",
      "address": "Address 0",
      "id": 1
    },
    {
      "name": "Customer 1",
      "lastName": "Customer Lastname 1",
      "address": "Address 1",
      "id": 2
    },
    {
      "name": "Customer 2",
      "lastName": "Customer Lastname 2",
      "address": "Address 2",
      "id": 3
    },
    ....

Second call :

{
  "elapsedTimeMilliseconds": 0,
  "customers": [
    {
      "name": "Customer 0",
      "lastName": "Customer Lastname 0",
      "address": "Address 0",
      "id": 1
    },
    {
      "name": "Customer 1",
      "lastName": "Customer Lastname 1",
      "address": "Address 1",
      "id": 2
    },
    {
      "name": "Customer 2",
      "lastName": "Customer Lastname 2",
      "address": "Address 2",
      "id": 3
    },
    ....

As you can see, loading a large number of records takes some time (between 150 to 1224 ms on my machine) on the first load, but then drops to 0 ms for subsequent calls because we put the data in our cache.

In our app example, we set a cache expiration value of 20 seconds, so once the 20 seconds are up, we will reload the data from the database and cache it for the next 20 seconds.

Conclusion

In the example we just saw, it was a small application that tries to retrieve a large number of data that we are going to put in a memory cache.
In the case of distributed applications you will have to use a distributed cache such as Redis or memcached.
You can find in the link below a very small application that uses Redis :
https://github.com/kbourzayq/RedisDemo

The idea of this example is to explain how we can implement the Repository pattern by caching the data to have high performance in the case where we have data that has a very minimal change frequency.
I hope this article was clear for you and do not hesitate to leave your comments if you see that it needs improvements.

See you next post in the next few days.