DEV Community: thecodewrapper

The Evolution of the Developer in the Era of AI Agents

thecodewrapper — Fri, 20 Feb 2026 15:58:27 +0000

Over the past days, a recurring theme has surfaced in conversations with colleagues — often not in formal meetings, but around lunch tables, coffee machines, and hallway chats. The topic is unavoidable: AI coding agents. Alongside the excitement sits a quiet, restrained anxiety. What happens to software developers when machines can write code?

My perspective is neither alarmist nor dismissive. Yes, change is coming — profound change. But no, the developer role is not disappearing. What we are witnessing is not extinction. It is evolution.

And like most technological shifts in our field, this one will likely unfold in stages.

From Tool to Teammate

Historically, programming tools have always evolved to increase abstraction. We moved from assembly language to high-level languages, from manual memory management to managed runtimes, from bare-metal development to frameworks and platforms, and from manual deployments to fully automated cloud pipelines. Each step reduced the need to write repetitive or low-level code while increasing the importance of design, intent, and problem understanding.

AI coding agents represent the next layer of abstraction — one that operates not on syntax, but on intent expressed in natural language. They do not merely autocomplete lines of code; they can generate entire modules, tests, documentation, and even deployment configurations. In effect, they begin to resemble junior collaborators rather than tools.

But collaborators still need direction, context, and oversight.

Phase 1: The Mild Shift — From Writing Code to Reviewing It

The first noticeable transition is already underway, and many teams are already experiencing it. Developers are writing less raw code themselves and spending more time evaluating code produced by AI systems. The daily workflow begins to resemble that of a reviewer or editor rather than a manual implementer.

In this phase, developers increasingly articulate requirements through structured prompts, examine generated code for correctness and security, refactor outputs to meet production standards, validate edge cases, and ensure consistency with existing systems. The role shifts toward verifying that the solution behaves as intended and integrates safely into a larger codebase.

What does not change is the need for critical thinking. AI can produce code that is syntactically correct but inefficient, fragile under edge conditions, insecure, or misaligned with business rules and architectural constraints. Review, therefore, becomes the primary skill. Writing code transforms into a process of expressing intent clearly and then verifying the machine’s interpretation.

Interestingly, this shift may affect junior developers first. Historically, early-career engineers added value through volume of implementation. When that volume can be generated automatically, experience becomes the differentiator. Engineers who can detect subtle flaws, foresee downstream consequences, and maintain system coherence become significantly more valuable.

Phase 2: The Significant Shift — Developers as Architects

As AI agents grow more capable, the transformation becomes more profound. Developers cease to be primarily implementers and evolve into system designers and orchestrators. The central question moves away from “How do I code this?” toward “What system should exist, and what properties must it satisfy?”

Responsibilities expand into areas traditionally associated with senior engineers or software architects. Developers must define domain boundaries, select architectural patterns, design data flows, and plan for scalability and resilience from the outset. They must also consider performance characteristics and resource efficiency, since AI-generated solutions are not inherently optimized. Decisions about latency, throughput, and cloud costs become part of everyday engineering judgment.

Operational excellence becomes equally central. Modern software is not simply a collection of source files but a living system deployed across infrastructure, monitored continuously, and expected to remain reliable under unpredictable conditions. Engineers must therefore design for observability, deployment strategies, fault tolerance, security posture, and regulatory compliance. In essence, the role shifts from building components to engineering systems.

Why Developers Will Not Disappear

Despite rapid advances, several fundamental factors make full replacement of developers unlikely.

Software does not exist in isolation; it exists within a socio-technical environment shaped by business goals, organizational constraints, legal obligations, human workflows, and political realities. AI systems have no stake in these contexts. Humans interpret them, negotiate them, and translate them into technical solutions.

Moreover, ambiguity is the default state of real-world projects. Requirements are often incomplete or contradictory. Stakeholders change priorities, discover new needs, or disagree with one another. AI performs best when the problem is clearly defined, but much of software engineering involves clarifying the problem itself.

Accountability is another critical dimension. When a system fails, organizations require someone to explain what happened, determine responsibility, and guide remediation. Machines cannot be held accountable in any meaningful organizational sense.

Finally, innovation depends on judgment. AI excels at extrapolating from existing patterns, but breakthrough ideas frequently arise from cross-domain thinking, intuition, and risk-taking — qualities rooted in human experience rather than statistical prediction.

A New Skill Set Emerges

If routine coding becomes partially commoditized, new differentiators emerge. Future high-value developers will need to communicate precisely, because expressing intent clearly becomes the foundation for effective collaboration with AI systems. Prompting is not merely typing instructions; it is structured problem formulation grounded in domain knowledge.

Equally important is the ability to evaluate outputs critically. Engineers must recognize when a solution appears correct but contains hidden flaws, performance pitfalls, or security vulnerabilities. This requires deep understanding rather than surface familiarity.

Architectural thinking becomes central as well. Developers must reason about systems at multiple levels of abstraction, connecting business objectives to technical implementation and infrastructure realities. Knowledge across disciplines — product design, operations, data management, and security — increasingly defines expertise.

The Risk Is Not AI — It Is Stagnation

The real danger facing developers is not replacement by machines, but obsolescence through resistance to change. Our industry consistently rewards those who adopt new abstractions early. Engineers who remained tied to assembly were overtaken by those who embraced high-level languages. Those who resisted frameworks or cloud computing found themselves outpaced by those who leveraged them.

AI agents represent another step on this same trajectory. The competitive advantage will belong to those who learn to direct these tools effectively rather than compete with them at tasks they are designed to automate.

A More Human Role, Not a Less Human One

Paradoxically, as machines assume mechanical tasks, the remaining work becomes more human. Judgment, creativity, empathy for users, ethical reasoning, and leadership grow in importance. Software development may shift from a craft dominated by syntax toward one centered on decision-making and problem solving.

In this sense, AI may elevate the profession rather than diminish it. Developers will spend less time translating ideas into code and more time shaping what should be built and why.

Final Thoughts

We are not approaching the end of the developer profession. We are approaching the end of the developer as a code-producing machine.

The future developer more closely resembles a systems thinker, architect, reviewer, integrator, and product-aware engineer. AI coding agents will transform how software is created, but not the need for human direction, responsibility, and insight.

The question is not whether developers will remain relevant.

The question is what kind of developers we choose to become.

The 3 Most Practical Features of C# 14 for Everyday Developers

thecodewrapper — Sun, 21 Sep 2025 10:21:58 +0000

C# 14 is just around the corner, and it ships alongside .NET 10, the next big milestone for the .NET ecosystem.
The official release of .NET 10 is scheduled for November 2025, and it will be a Long-Term Support (LTS) release — meaning you’ll get free patches and updates for three years.

Even though the final release isn’t here yet, the Release Candidate (RC) for .NET 10 is already available. That means you can start experimenting with C# 14 today, try out its new language features, and get a head start on upgrading your apps.

In this post, we’ll explore the 3 most practical features of C# 14 for everyday developers, with clear explanations, before-and-after examples, and practical tips for when to use each feature.

Null-Conditional Assignment

Null-checking before an assignment is one of the most repetitive tasks in C#. Previously, you had to guard every assignment with an if statement, which bloated code and added indentation. This feature removes that noise while still being safe.

// Before C#14
if (customer is not null)
{
    customer.Order = GetCurrentOrder();
}

C# 14 now allows you to use ?. and ?[] on the left-hand side of an assignment (or compound assignment like +=). If the receiver is null, the assignment is skipped with no exceptions thrown.

// With C#14
customer?.Order = GetCurrentOrder();

The right side of the = operator is evaluated only when the left side isn’t null. If customer is null, the code doesn’t call GetCurrentOrder.

Caveats

The right-hand side won’t be evaluated if the receiver is null — don’t put important side effects there if they must always run.
Doesn’t work with increment/decrement operators (++ or --). Only assignment and compound assignment are supported.

The `field` Keyword

Up until now, if you wanted to enforce a rule in a property setter (like preventing null assignments), you had to create a separate backing field and write both accessors yourself, losing the simplicity of auto-properties.

In the example below, we’re forced to introduce a _message field just so we can add a null check in the setter.

// Before C#14
private string _message;
public string Message
{
    get => _message;
    set => _message = value ?? throw new ArgumentNullException(nameof(value));
}

C# 14 introduces the field keyword, which allows you to reference the compiler-generated backing field of an auto-property directly. This means you can add logic to a property accessor without having to manually declare and manage a private field.

// With C#14
public string Message
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(value));
}

The field token is replaced by the compiler with a synthesized backing field. You still get a fully functioning auto-property, but with custom accessor logic.

Caveats

If your type already has a member named field, this could be confusing. You can disambiguate by using @field or this.field, or (better) rename the existing member.
Remember that field only exists inside the property accessor body — it’s not available anywhere else.

Extension Members and the Extension Syntax

Extension methods were a big deal when they were added in C# 3.0 — they let you add functionality to existing types (like LINQ does) without modifying them.
But methods were all you could add — no properties, no operators, no static helpers. C# 14 removes those limitations.

C# 14 introduces a new syntax for extension members, letting you do more than just add methods.

With the new extension blocks, you can now declare:

Extension properties — so you can call obj.MyProperty on types you don’t own.
Static extension members — members that appear as if they’re part of the type itself.
User-defined operators — adding custom operators like +, -, or even comparison operators to existing types.

This makes extensions feel more natural, letting you express domain logic as if you had direct control over the type.

// Before C#14
public static class ListExtensions
{
    public static bool IsEmpty<T>(this List<T> list)
        => list.Count == 0;

    public static List<T> Combine<T>(this List<T> list, List<T> other)
        => list.Concat(other).ToList();
}

var list1 = new List<int> { 1, 2, 3 };
var list2 = new List<int> { 4, 5, 6 };

if (list1.IsEmpty()) { /* ... */ }

var combined = list1.Combine(list2);

// With C#14
public static class ListExtensions
{
    // Instance-style extension members
    extension<T>(List<T> list)
    {
        public bool IsEmpty => list.Count == 0;
    }

    // Static (type-level) extension members
    extension<T>(List<T>)
    {
        public static List<T> operator +(List<T> first, List<T> second)
            => first.Concat(second).ToList();

        public static List<T> Empty => new();
    }
}

var list1 = new List<int> { 1, 2, 3 };
var list2 = new List<int> { 4, 5, 6 };

if (list1.IsEmpty) { /* ... */ }
var combined = list1 + list2;
var emptyList = List<int>.Empty;

Extensions now look and behave like native members of the type.

When to Use

Adding semantic helpers to framework types (like .IsEmpty or .FullName).
Providing type-level utilities (like List<T>.Empty or DateOnly.Today).
Defining domain-specific operators (e.g. + for combining domain objects).

Caveats

Keep it intuitive — avoid adding operators or properties that surprise readers.
Remember that extension members are still syntactic sugar — they don’t actually modify the type.
Consider discoverability: too many extension blocks scattered across namespaces can confuse users.

Conclusion

C# 14 is a refinement release that focuses on making everyday code cleaner and more expressive.

With null-conditional assignment, you eliminate repetitive null checks. With the field keyword, you get custom logic on auto-properties without sacrificing simplicity. And with extension members, you can make your code feel more natural by adding properties, operators, and utilities to types you don’t own.

These features may seem small at first glance, but they add up to a more elegant developer experience — fewer lines of boilerplate, less ceremony, and more readable code.

For more features and full details on what’s new in C# 14, check out “What’s new in C# 14” on Microsoft Learn.

How to: Properly Simulate a Race Condition in C#

thecodewrapper — Sat, 15 Feb 2025 08:29:46 +0000

Race conditions are one of the trickiest and most elusive bugs in multithreaded programming. They occur when multiple threads access and modify shared data simultaneously, leading to unpredictable results.

In this article, we will explore how to intentionally create a race condition, analyze why it happens, and demonstrate the best ways to properly simulate a race condition in C#.

Understanding a Race Condition with a Simple Counter

Before diving into real-world examples, let’s start with a simple demonstration using a counter. This example shows a basic race condition where multiple threads increment a shared variable.

using System;
using System.Threading;

class Program
{
    static int counter = 0;

    static void IncrementCounter()
    {
        for (int i = 0; i < 1000; i++)
        {
            counter++; // NOT ATOMIC → Race condition occurs
        }
    }

    static void Main()
    {
        Thread thread1 = new Thread(IncrementCounter);
        Thread thread2 = new Thread(IncrementCounter);

        thread1.Start();
        thread2.Start();

        thread1.Join();
        thread2.Join();

        Console.WriteLine($"Final counter value: {counter} (Expected: 2000)");
    }
}

Why is this a race condition?

The statement counter++ is not atomic; it consists of three operations:

Read counter value.
Increment the value.
Store the updated value back. When multiple threads execute this statement simultaneously, they may read the same initial value before either writes it back, leading to lost updates.

This example demonstrates a race condition, but in practical applications, race conditions often involve more than just a counter. Let’s now look at a real-world scenario and test different ways to create a race condition.

A More Real-World Example: Bank Account Transactions

In this example, we will use a bank account withdrawal system where multiple users attempt to withdraw money simultaneously. This allows us to observe how race conditions might affect financial transactions.

If a race condition occurs, we might see an incorrect final balance, such as a negative value, indicating that multiple threads withdrew money at the same time without proper synchronization. If no race condition occurs, we would expect the final balance to be exactly 0 after all withdrawals are complete.

using System;
using System.Threading;

class BankAccount
{
    private int _balance;

    public int GetBalance() => _balance;
    public BankAccount(int initialBalance) {
        _balance = initialBalance;
    }

    public void Withdraw(int amount) {
        if (_balance > 0) {
            _balance -= amount;
        }
    }
}

class Program
{
    static void Main() {
        BankAccount account = new BankAccount(1000);
        int threadCount = 15;
        Thread[] threads = new Thread[threadCount];

        for (int i = 0; i < threadCount; i++) {
            threads[i] = new Thread(() => account.Withdraw(100));
            threads[i].Start();
        }

        foreach (var thread in threads)
            thread.Join();

        Console.WriteLine($"Final account balance: {account.GetBalance()} (Expected: 0 or negative value if a race condition occurs)");
    }
}

Is this guaranteed to create a race condition however? The answer is no, because of thread-scheduling, CPU allocation and memory optimizations.

Thread Scheduling is Non-Deterministic

The OS scheduler decides when to switch between threads, meaning that execution order is unpredictable. Sometimes, one thread may complete all its operations before another even starts, reducing contention. Other times, two or more threads might execute _balance -= amount concurrently, leading to lost updates or corrupted values.

CPU Speed and Core Allocation

If the CPU switches context too slowly, a single thread may complete multiple operations before another thread gets a chance to run, effectively eliminating the possibility of interleaved execution. Additionally, if the CPU schedules each thread to a separate core, operations may be executed in a sequential rather than interleaved manner, further reducing the likelihood of a race condition occurring.

JIT Optimizations & Memory Reordering

The .NET JIT compiler may optimize code execution differently across runs. This means that even identical code can produce varying results based on how the compiler decides to optimize memory accesses. Additionally, modern CPUs may reorder memory writes, meaning that updates made by one thread may not be immediately visible to another, sometimes preventing or delaying expected conflicts.

Evidently, this means that while race conditions can happen, they are not guaranteed every time the program is run.

What if we increase thread count to 1000?

In an attempt to increase the likelihood of encountering a race condition, we can significantly raise the number of concurrent threads operating on the shared resource. The idea is that a higher number of threads will lead to more simultaneous access, increasing contention.

static void Main()
{
    BankAccount account = new BankAccount(1000);
    int threadCount = 1000;
    Thread[] threads = new Thread[threadCount];

    for (int i = 0; i < threadCount; i++)
    {
        threads[i] = new Thread(() => account.Withdraw(100));
        threads[i].Start();
    }

    foreach (var thread in threads)
        thread.Join();

    Console.WriteLine($"Final account balance: {account.GetBalance()} (Expected: 0 or negative value if a race condition occurs)");
}

Increasing thread count makes issues more likely, but it does not guarantee a race condition every time.

In fact, instead of a clear race condition, you may just experience performance degradation. The final value of the counter may sometimes be close to the expected value if most threads execute sequentially rather than in parallel. However, due to random interleaving, there may still be occasional incorrect values, making the race condition inconsistent and difficult to reproduce reliably.

So, how do we reliably maximize our chances to create a race condition?

Ensuring a Race Condition Always Occurs

Adding artificial delays such as Thread.Sleep(1) inside the Withdraw method increases the likelihood of a race condition happening every time.

public void Withdraw(int amount)
{
    if (_balance > 0)
    {
        Thread.Sleep(1); // Force a small delay to increase interleaving
        _balance -= amount;
        Console.WriteLine($"{Thread.CurrentThread.Name} withdrawing... Current Balance After: {_balance}");
    }
}

By pausing execution at a crucial moment, this approach ensures that multiple threads access and modify _balance at the same time, making the race condition visible in every execution.

Why does this happen?

Thread.Sleep(1) causes a race condition because it forces the operating system to pause execution of the current thread and allow other threads to run. This interruption occurs after the balance check (_balance > 0) but before updating _balance, creating a window where another thread can enter the method, read the same (stale) balance, and proceed with its own withdrawal.

Since both threads see the same initial balance before either updates it, they perform calculations based on stale data, leading to incorrect final values.

Without Thread.Sleep(1), the race condition might occur unpredictably based on system load and thread scheduling, but with it, the problem is consistently reproduced, making it easier to observe and debug.

A More Natural Way – Using a Semaphore to Force Contention

While adding artificial delays – almost – guarantees a race condition, using a semaphore provides a more structured way to test for it. Instead of relying on CPU timing and artificial delays, we can line up threads at the race point and use a semaphore to release them all simultaneously. This method ensures that multiple threads enter the critical section together, increasing contention naturally.

class BankAccount
{
    private int _balance;

    public int GetBalance() => _balance;
    public BankAccount(int initialBalance) {
        _balance = initialBalance;
    }

    public void Withdraw(int amount) {
        if (_balance > 0) {
            _balance -= amount;
            Console.WriteLine($"{Thread.CurrentThread.Name} withdrawing... Current Balance After: {_balance}");
        }
    }
}

class Program
{
    static void Main() {
        BankAccount account = new BankAccount(1000);
        int threadCount = 150;
        Thread[] threads = new Thread[threadCount];
        SemaphoreSlim semaphore = new SemaphoreSlim(0); // Initially locked

        for (int i = 0; i < threadCount; i++) {
            threads[i] = new Thread(() =>
            {
                semaphore.Wait();
                account.Withdraw(100);
            });
            threads[i].Start();
        }

        Thread.Sleep(1000); //Wait for all threads to start

        Console.WriteLine("Releasing all threads at once...");
        semaphore.Release(threadCount); // Release all threads at once!

        foreach (var thread in threads) {
            thread.Join();
        }

        Console.WriteLine($"Final account balance: {account.GetBalance()} (Expected: Negative value due to race condition)");
    }
}

By using a semaphore to hold back all threads and then releasing them simultaneously, we increase the chances of multiple threads attempting to modify the shared resource at the exact same time. This forces the race condition to occur more predictably, making it easier to observe and analyze.

Of course, in this specific example, it is likely that no race condition will actually occur when you run the code. The reason is that the decrement operation (_balance -= amount;) executes so quickly that the chances of interleaving between threads are extremely low. Since there are no artificial delays (Thread.Sleep) or additional read-modify-write steps before the subtraction, most CPUs will execute each withdrawal sequentially rather than in parallel.

The OS scheduler may also serialize execution across threads, reducing the possibility of lost updates. This means that while multiple threads are running, each thread is likely seeing and modifying the most recent value of _balance rather than an outdated one.

Despite that, this approach simulates contention in a structured way, allowing you to test for race conditions without relying on unpredictable delays.

Conclusion

Detecting and understanding race conditions is crucial for writing reliable and thread-safe code. The most effective way to reliably reproduce a race condition is to synchronize all competing threads at a single execution point and release them simultaneously, as demonstrated with the semaphore approach.

By structuring your tests to create contention at the right moment, you can gain insight into how concurrent operations interact and identify potential synchronization issues.

If you are developing a multithreaded application, incorporating controlled race condition testing into your workflow can help prevent subtle concurrency bugs before they reach production.

A consolidated guide to Well-Architected Frameworks

thecodewrapper — Fri, 09 Aug 2024 00:08:15 +0000

In this post, we will delve into the core principles and guidance of the Well-Architected Frameworks (WAF) of Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP). We’ll highlight the pillars that form the foundation of these frameworks: Cost Optimization, Operational Excellence, Performance Efficiency, Reliability, Security, and Sustainability. Each pillar provides a lens through which architects can evaluate their current setups and identify areas for enhancement. Together they will form a consolidated guide to Well-Architected frameworks.

Moreover, as cloud strategies often span multiple cloud platforms, we’ll introduce steps and considerations for implementing these best practices within any cloud environment.

This comprehensive approach will empower you to create a holistic, well-architected cloud infrastructure that leverages the strengths of Azure, AWS, or GCP.

The following guide is meant to serve as an overview of various principles and approaches from the aforementioned WAFs, providing an understanding of how to build and maintain efficient, secure, and sustainable cloud infrastructures across different platforms.

Reliability

The Reliability pillar in cloud architecture focuses on ensuring that workloads can recover from failures, meet customer demands, and remain operational over time. The goal is to build a resilient infrastructure that can handle disruptions gracefully, maintain consistent performance, and recover quickly from outages or issues. This pillar is crucial for providing a positive user experience and maintaining business continuity.

Design for Business Requirements: Gather business requirements with a focus on the intended utility of the workload.

Design for Resilience: The workload must continue to operate with full or reduced functionality.

Design for Recovery: The workload must be able to anticipate and recover from most failures, of all magnitudes, with minimal disruption to the user experience and business objectives.

Design for Operations: Shift left in operations to anticipate failure conditions.

Keep it Simple: Avoid overengineering the architecture design, application code, and operations.

Design for Failure

To design for failure, adopt a distributed architecture by distributing workloads across multiple regions and availability zones to avoid a single point of failure. Ensure graceful degradation so that if part of the system fails, it does so without affecting overall functionality.

Implement Backup and Restore Procedures

Implementing backup and restore procedures involves scheduling regular backups for critical data. Regularly test the restore process to ensure data integrity and availability.

Utilize Redundancy and Replication

To utilize redundancy and replication, use redundant components like databases and servers to ensure system reliability. Implement data replication across different geographical locations to protect against data loss.

Monitoring and Alerting

For effective monitoring and alerting, use tools for real-time monitoring to gain insights into system performance and health. Set up alerts and notifications for critical metrics and events to enable a prompt response to issues.

Implement Scalability and Elasticity

To implement scalability and elasticity, utilize auto-scaling features to adjust resources based on demand. Employ load balancing to distribute incoming traffic across multiple servers, ensuring no single server is overwhelmed.

Ensure Disaster Recovery

To ensure disaster recovery, develop and maintain a disaster recovery plan that includes RTO (Recovery Time Objective), RPO (Recovery Point Objective), and RLO (Recovery Level Objective) targets. Conduct DR drills regularly to ensure readiness and efficiency.

Automated and Manual Recovery Procedures

For effective recovery procedures, implement automated healing mechanisms that detect and remediate failures automatically. Maintain detailed runbooks for manual intervention when automated recovery is insufficient.

Security and Compliance

To maintain security and compliance, implement strict access controls to protect infrastructure from unauthorized changes that can lead to failures. Ensure compliance monitoring to adhere to relevant regulations and standards, avoiding disruptions due to non-compliance.

Best Practices

Adopting best practices involves decoupling components to reduce the impact of a failure in one component on the overall system. Use managed services offered by cloud providers to offload the operational burden and gain built-in reliability features. Keep systems up to date with regular updates and patching to avoid vulnerabilities and improve stability. Regularly conduct capacity planning to ensure the system can handle future growth. Implement failover mechanisms to switch to backup systems automatically during failures.

Security

The Security pillar in cloud architecture emphasizes protecting data, systems, and assets through rigorous security controls. This includes ensuring confidentiality, integrity, and availability of data, implementing strong identity management, detecting and responding to threats, and maintaining compliance with regulatory requirements. Security is foundational to maintaining trust and protecting organizational assets.

Plan your security readiness: Strive to adopt and implement security practices in architectural design decisions and operations with minimal friction.

Design to protect confidentiality: Prevent exposure to privacy, regulatory, application, and proprietary information through access restrictions and obfuscation techniques.

Design to protect integrity: Prevent corruption of design, implementation, operations, and data to avoid disruptions that can stop the system from delivering its intended utility or cause it to operate outside the prescribed limits. The system should provide information assurance throughout the workload lifecycle.

Design to protect availability: Prevent or minimize system and workload downtime and degradation in the event of a security incident by using strong security controls. You must maintain data integrity during the incident and after the system recovers.

Sustain and evolve your security posture: Incorporate continuous improvement and apply vigilance to stay ahead of attackers who are continuously evolving their attack strategies.

Implement Identity and Access Management (IAM)

To effectively implement Identity and Access Management (IAM), apply the principle of least privilege by granting only the permissions necessary for users to perform their tasks. Enforce multi-factor authentication (MFA) for an additional layer of security. Conduct regular audits of permissions and access policies to maintain security integrity. Make use of techniques like Just-In-Time (JITA), Just-Enough (JEA) access.

Protect Data at Rest and in Transit

To protect data at rest and in transit, use encryption to safeguard sensitive information. Implement robust key management practices and utilize managed key services. Data classification is essential to apply appropriate security controls based on the sensitivity of the data.

Detect and Respond to Threats

To detect and respond to threats, implement continuous monitoring to identify suspicious activities and potential threats. Develop and regularly update an incident response plan to ensure preparedness. Utilize Security Information and Event Management (SIEM) tools to aggregate and analyze security data.

Implement Network Security Controls

For effective network security controls, practice network segmentation to isolate critical resources and limit the impact of potential attacks. Use firewalls and security groups to manage inbound and outbound traffic. Employ Virtual Private Networks (VPNs) for secure connections to cloud resources.

Maintain Compliance and Governance

To maintain compliance and governance, implement security controls based on relevant compliance frameworks such as GDPR and HIPAA. Regularly audit and report on security practices to demonstrate compliance. Develop and enforce comprehensive policy management across the organization.

Best Practices

Adopting best practices includes integrating security by design into the architecture’s design phase. Ensure regular patching and updates to keep systems and applications secure with the latest fixes. Provide ongoing security training and awareness programs for employees. Use automation to enforce security policies, monitor for threats, and respond to incidents. Engage in third-party audits to assess your security posture and identify potential vulnerabilities.

Cost optimization

The Cost Optimization pillar focuses on controlling and minimizing costs while maximizing the value delivered by cloud investments. Effective cost management involves understanding and managing where money is being spent, selecting the right services for the right workloads, and continuously optimizing usage to align with business needs and budget constraints.

Develop cost-management discipline: Build a team culture that has awareness of budget, expenses, reporting, and cost tracking.

Design with a cost-efficiency mindset: Spend only on what you need to achieve the highest return on your investments. Develop a “spend-it-like-it’s-yours” mentality.

Design for usage optimization: Maximize the use of resources and operations. Apply them to the negotiated functional and nonfunctional requirements of the solution.

Design for rate optimization: Increase efficiency without redesigning, renegotiating, or sacrificing functional or nonfunctional requirements.

Monitor and optimize over time: Continuously right-size investment as your workload evolves with the ecosystem.

Implement Cost Transparency and Monitoring

To implement cost transparency and monitoring, you should tag resources to allocate costs to different projects, departments, or business units. Additionally, using cost management tools will help you monitor and visualize spending patterns. Setting up budgets and alerts is essential to track spending and avoid unexpected costs.

Manage Resource Utilization

Effective management of resource utilization involves regularly reviewing and managing your resource inventory to identify unused or underutilized resources. Using automated scheduling to start and stop resources based on usage patterns can greatly enhance efficiency. Moreover, archiving or deleting obsolete data and resources helps in reducing storage costs.

Right-Size Resources

To ensure resources are right-sized, you should continuously monitor resource performance to avoid over-provisioning or underutilization. Implementing autoscaling can help adjust resource capacity based on demand, and selecting the most cost-effective instance types that meet performance requirements is crucial.

Use Appropriate Pricing Models

Choosing appropriate pricing models can significantly cut costs. Committing to reserved instances or savings plans for predictable workloads is beneficial. For non-critical workloads that can tolerate interruptions, utilizing spot instances or preemptible VMs is ideal. Additionally, taking advantage of discount programs offered by cloud providers can lead to further savings.

Automate Cost Management

Automate cost management by using automation tools to enforce cost management policies and optimize resource usage. Implementing policy enforcement can automatically terminate unused resources or downsize over-provisioned ones. Utilizing automated analysis tools can help identify cost-saving opportunities.

Best Practices

To optimize storage costs, use appropriate storage classes and lifecycle policies. Leverage managed services to reduce operational overhead and infrastructure management costs. Conducting regular audits of resource usage and costs can uncover optimization opportunities. Enhancing training and awareness among teams on cost management best practices and the financial impacts of their decisions is also important. Finally, performing cost-benefit analyses for new services or architectural changes ensures they provide value for money.

Performance Efficiency

The Performance Efficiency pillar focuses on using IT and computing resources efficiently to meet system requirements, and maintaining that efficiency as demand changes and technologies evolve. This involves selecting the right resource types and sizes, monitoring performance, and making informed choices to balance cost and performance.

Negotiate realistic performance targets: The intended user experience is defined, and there’s a strategy to develop a benchmark and measure targets against the pre-established business requirements.

Design to meet capacity requirements: Provide enough supply to address anticipated demand.

Achieve and sustain performance: Protect against performance degradation while the system is in use and as it evolves.

Improve efficiency through optimization: Improve system efficiency within the defined performance targets to increase workload value.

Optimize Resource Selection

To optimize resource selection, practice right sizing by choosing appropriate resource types and sizes based on workload requirements. Leveraging managed services allows you to benefit from the expertise of cloud providers. Adopting modern architectures, such as serverless and microservices, is beneficial where appropriate.

Continuous Performance Monitoring

Engage in continuous performance monitoring by tracking key performance metrics to ensure resources perform as expected. Implement logging and analysis to understand system performance and identify bottlenecks. Monitoring user experience metrics is crucial to ensure end-user satisfaction.

Implement Elasticity

To effectively implement elasticity, utilize auto-scaling to dynamically adjust resource capacity based on demand. Employ load balancing to distribute traffic efficiently across resources, preventing any single resource from being overwhelmed. Using buffering through queues and buffers helps manage load spikes and ensures smooth processing.

Continuous Optimization

Engage in continuous optimization by regularly benchmarking your system to understand its performance under various conditions. Refine and improve resource allocation continuously based on performance data. Implement caching strategies to reduce latency and improve response times.

Encourage Experimentation and Innovation

Encourage experimentation and innovation by using A/B testing to compare different configurations and identify the best-performing setup. Prototype new architectures and services to discover the most efficient solutions. Stay updated with innovation in new technologies and approaches to continuously improve performance.

Best Practices

Adopting best practices means staying adaptable and ready to adapt to change by implementing new technologies and methodologies that can enhance performance. Continuously evaluate the cost-performance balance to ensure optimal resource utilization. Automation of performance monitoring and optimization processes ensures consistent and efficient application. Designing systems with a user-centric design ensures that performance improvements directly impact user satisfaction. Establish feedback loops to continually learn from performance data and make iterative improvements.

Operational Excellence

The Operational Excellence pillar focuses on running and monitoring systems to deliver business value and continually improving processes and procedures. This includes designing and managing workloads that can adapt to changes, recovering quickly from failures, and providing insights into operations for better decision-making. Ensuring operational excellence involves automating tasks, managing configurations, monitoring operations, and improving processes through iteration.

Embrace DevOps culture: Empower development and operations teams to continuously improve their system design and processes by working together with a mindset of collaboration, shared responsibility, and ownership.

Establish development standards: Optimize productivity by standardizing development practices, enforcing quality gates, and tracking progress and success through systematic change management.

Evolve operations with observability: Gain visibility into the system, derive insight, and make data-driven decisions.

Deploy with confidence: Reach the desired state of deployment with predictability.

Automate for efficiency: Replace repetitive manual tasks with software automation that completes them quicker, with greater consistency and accuracy, and reduces risks.

Adopt safe deployment practices: Implement guardrails in the deployment process to minimize the effect of errors or unexpected conditions.

Gain Operational Insights

To gain operational insights, implement comprehensive monitoring to gather data on system health and performance. Enable logging to capture detailed information about system operations and issues. Define key metrics and set up alerts for critical thresholds to detect and respond to issues quickly.

Automate Operational Tasks

Automating operational tasks involves using Infrastructure as Code (IaC) to automate infrastructure provisioning and management. Implement automated testing to ensure systems are working as expected after changes, and use deployment automation to streamline and standardize application deployments.

Manage Configurations

Effective configuration management requires using Configuration as Code to ensure consistency and enable version control. Centralize management to simplify updates and ensure compliance, and use secure methods for secret management to handle sensitive configuration data.

Efficient Change Management

For efficient change management, track changes to understand their impact on system operations. Use controlled rollouts such as phased rollouts and canary deployments to minimize the impact of changes. Establish rollback procedures to quickly revert changes if issues are detected.

Continuous Improvement

To foster continuous improvement, establish feedback loops to gather insights from operations and users. Conduct blameless analysis and debrief post-release and/or post-release reviews to identify root causes and preventive measures. Continuously make iterative improvements to enhance operational efficiency and reliability.

Best Practices

Adopting best practices involves maintaining comprehensive documentation of operational procedures and best practices. Regularly train staff and encourage knowledge sharing to maintain high operational standards. Regularly test the resilience and recovery procedures to ensure they are effective. Establish performance benchmarks and review them regularly to ensure systems meet expected standards. Foster a culture of collaboration and communication among teams to enhance operational efficiency.

Sustainability

The Sustainability pillar focuses on minimizing the environmental impact of cloud operations. This involves reducing energy consumption, optimizing resource utilization, leveraging renewable energy sources, and designing applications and infrastructure that support sustainability goals. Achieving environmental sustainability requires a comprehensive approach that encompasses both technical and operational strategies to reduce the carbon footprint and promote efficient use of resources.

Energy Efficiency: Reducing the energy consumption of cloud resources.

Resource Optimization: Utilizing cloud resources efficiently to minimize waste.

Sustainable Infrastructure: Leveraging infrastructure that supports sustainability goals.

Renewable Energy: Using renewable energy sources to power cloud operations.

Design for Sustainability: Incorporating sustainability into the design of applications and services.

Improve Energy Efficiency

To improve energy efficiency, use energy-efficient hardware and leverage cloud providers’ efforts to enhance data center efficiency. Schedule workloads through workload scheduling to run during off-peak hours, reducing energy usage. Additionally, maximize server utilization to ensure efficient use of energy resources.

Optimize Resource Utilization

For optimizing resource utilization, choose appropriate resource types and sizes through right-sizing to avoid over-provisioning. Implement auto-scaling to dynamically adjust resources based on demand. Regularly review and deprovision unused or underutilized resources to reduce waste.

Leverage Sustainable Infrastructure

To leverage sustainable infrastructure, use cloud providers that operate green data centers with certifications like LEED. Select data center locations through geographical selection based on their environmental impact and energy sources. Adopt cloud providers’ sustainable practices, such as using water-efficient cooling systems.

Utilize Renewable Energy

For utilizing renewable energy, support cloud providers that purchase renewable energy credits (RECs) to offset their carbon footprint. Choose providers that directly use renewable energy sources for their operations. Partner with cloud providers committed to achieving carbon-neutral goals.

Design for Sustainability

To design for sustainability, engage in sustainable software development by designing applications to be energy-efficient and minimize resource consumption. Use serverless architectures to optimize resource usage and reduce idle capacity. Regularly review and continuously improve applications and infrastructure to enhance sustainability.

Best Practices

Adopt best practices by using monitoring tools to monitor energy consumption and identify opportunities for improvement. Educate teams about the importance of sustainability and best practices. Define and track sustainability metrics to measure progress and impact. Collaborate with cloud providers and industry partners through collaboration and partnerships to share best practices and drive sustainability initiatives. Continuously explore new technologies and approaches for innovation to further reduce environmental impact.

Resources

Here are the links to dive deeper into the well-architected frameworks of each cloud provider:

Azure Well-Architected Framework

AWS Well-Architected Framework

Google Cloud Architecture Framework

Conclusion

The well-architected frameworks from Azure, AWS, and Google Cloud are like your go-to guides for building great cloud systems. They cover everything you need to make sure your setups are reliable, secure, cost-effective, and ready for anything.

Reliability: Keep your systems solid and able to recover from issues with strategies like backups and monitoring.
Security: Protect your data and apps by setting up strong security measures and keeping an eye out for threats.
Cost Optimization: Save money by picking the right resources, keeping track of spending, and optimizing where you can.
Performance Efficiency: Ensure your systems are responsive by choosing the right resources and scaling as needed.
Operational Excellence: Run your systems smoothly by automating tasks, managing changes well, and always looking for improvements.
Sustainability: Be environmentally friendly by using resources efficiently and opting for renewable energy.

By following these pillars, you can build cloud systems that are secure, efficient, cost-effective, and sustainable — basically, everything you need to keep your operations running smoothly and responsibly.

Unlock Your Potential: Building Custom Tools as a Developer

thecodewrapper — Mon, 30 Oct 2023 15:32:02 +0000

As a passionate advocate of custom tooling in the world of software development, I firmly believe that if you can build tools to make your work easier, you should go ahead and spend the time to do it. The dividends of investing in custom tools are immense and far-reaching. In this article, we’ll delve into the importance of building custom tools as a developer and explore how they can transform your work into a more efficient and rewarding endeavor.

Custom tools empower you as a developer to streamline your workflows, increase your productivity, and conquer complex tasks with ease, all while ensuring long-term benefits that are well worth the initial investment.

What are custom tools?

Firstly, custom tools are basically our sidekicks in the coding world. They’re tailor-made applications, scripts, or software solutions that we build to make our lives easier as developers. It’s like having a personal assistant that just gets you. We’re talking automation scripts that handle the boring, repetitive tasks, user-friendly graphical interfaces that turn complex problems into a walk in the park, plugins and extensions that supercharge our IDEs, data transformation tools that make sense of the mountains of data we deal with, and custom testing and debugging utilities that fit our projects like a glove.

They aren’t solely focused on making business processes more efficient; instead, their primary purpose is to optimize the work you do.

They are a reflection of the developer’s ingenuity, problem-solving skills, and deep understanding of the project’s unique demands.

Efficiency and Productivity

Now, why are these tools so darn great? They take our productivity to new heights, help us tackle even the most complex tasks with ease, and guarantee we’re set up for success in the long run. Plus, they’re just plain fun to build and use.

Imagine you’re a developer in a project and part of your daily routine is to convert huge datasets from one format to another, which takes a few minutes each time you do it, and also, you do it, say, 10 times a day. With a custom tool, that because way easier! You’ve got your handy dandy data conversion tool that’s been fine-tuned to handle the specific formats you work with. It automates the whole process and even runs in the background while you focus on the good stuff. The result? You’ve just upped your efficiency and productivity big time.

Addressing unique challenges

Every project and development team faces unique challenges. These challenges may range from complex data processing to intricate debugging scenarios. Custom tools allow developers to design solutions specifically attuned to the demands of their projects. By creating tools tailored to handle specific issues or scenarios, developers can eliminate bottlenecks and roadblocks more effectively.

For example, in your work, you may encounter complex challenges, such as managing inventory updates from multiple suppliers with varying data formats. By creating a custom data integration tool that understands each supplier’s format and automates the data import process, you can efficiently address this unique challenge, reducing errors and improving data accuracy.

Streamlining workflows

And let’s not forget about streamlining workflows. Custom tools are like the missing puzzle piece that fits perfectly into our development stacks. They automate those tedious steps, help us maintain top-notch coding standards, and provide intuitive interfaces that let us focus on the creative aspects of our work.

In a DevOps context, for example, a custom tool could be integrated into the CI/CD (Continuous Integration/Continuous Deployment) pipeline to automate the build, packaging, and deployment of applications and libraries. This ensures that code changes are automatically tested, built, and deployed, saving us heaps of time and maintaining consistency across development, testing, and production environments.

Skills Development

Building custom tools isn’t just about solving immediate problems; it’s also about growing as professionals. We get to hone our problem-solving skills, dive deep into programming languages and frameworks, and let our creative flags fly. It’s a great way to flex our coding muscles and learn something new.

Don’t be afraid to explore languages and frameworks you’ve never before worked with, to bring your tool to life. Diving deep into programming languages and frameworks, especially those we’re not super familiar with, is like opening a treasure trove of possibilities. It’s like, “Woah, I didn’t know this language could do that!” It’s a fantastic way to expand our toolkit and see which languages vibe with our way of solving problems. Plus, it gives us first-hand insights into the strengths and weaknesses of different languages. We might find that some languages are like our best friends for certain types of solutions, while others are more like that acquaintance we only call up for specific tasks.

It’s a super fun way to flex our coding muscles and learn something new, all while creating our personalized toolbox.

Cost savings

And, last, but not least, let’s talk about the financial side of things. While building custom tools does require a time investment upfront, the long-term benefits are well worth it. We can kiss those annoying licensing fees goodbye, cut down on the time we spend on manual tasks, and avoid those costly errors that can come from using inadequate tools.

Conclusion

In conclusion, custom tools are like our secret weapons in the coding world. They empower us to work smarter, tackle any challenge that comes our way, and grow as professionals. Plus, they save us money in the long run. So, let’s embrace the power of custom tools and take our development game to new heights of efficiency and excellence!

Simple Event-Sourcing with EF Core and SQL Server

thecodewrapper — Tue, 17 Oct 2023 13:25:24 +0000

In this article, I delve deeper into the architectural explorations that began with my initial post on ‘Implementing a Clean Architecture in ASP.NET Core 6‘. The spotlight this time is on implementing a rudimentary event-sourcing mechanism using Entity Framework Core and SQL Server.

While this article navigates the intricacies of my chosen implementation, it presumes you already have a foundational grasp of event sourcing, its association with event-driven architectures, and its synergy with patterns like Domain-Driven Design (DDD) and Command Query Responsibility Segregation (CQRS). If you’re looking to enhance your understanding of these underlying concepts or to garner insights on the merits and challenges of event-sourcing, I’ve assembled a list of resources at the conclusion of this article.

Core Abstractions

In event-sourcing, we often deal with large streams of events and need ways to efficiently recreate system state. Our three core interfaces handle these challenges: IEventStore manages event persistence and retrieval, IEventStoreSnapshotProvider uses snapshots for faster state reconstruction, and IRetroactiveEventsService deals with changes to past events.

Event persistence

IEventStore is central to our event-sourced system, serving as the interface for storing and retrieving domain events tied to aggregates. It manages the persistence of domain events for an aggregate and provides capabilities to fetch domain events based on a version range.

Snapshots

To optimize performance in scenarios with large event logs, IEventStoreSnapshotProvider offers snapshot functionality. Snapshots capture an aggregate’s state at a specific point in time, reducing the need to replay every event for aggregate rehydration. This interface deals with both the retrieval of an aggregate’s state from a snapshot and the persistence of an aggregate’s current state as a snapshot.

Retroactive events

For instances where we need to make adjustments to historical event streams, IRetroactiveEventsService comes into play. Whether for corrections, recalculations, or backdated operations, this interface facilitates the introduction of retroactive events into an existing event stream and returns the modified stream.

The Event Store

In this section, we’ll delve into the actual implementation details of our event store using Entity Framework. Our primary class, EFEventStore, provides concrete implementations for the essential operations defined in our IEventStore interface. With Entity Framework as its backbone, this class essentially persists and retrieves domain events to and from our data store.

Context and DbSet

At its core, EFEventStore relies on the EventStoreDbContext context. The context contains only one DbSet, the EventEntity DbSet, which represents the table where the domain events are stored.

private readonly EventStoreDbContext _context;
private readonly DbSet<EventEntity> _events;

public EFEventStore(EventStoreDbContext context) {
    _context = context;
    _events = _context.Set<EventEntity>();
}

Loading Domain Events

The LoadAsync method fetches a sequence of domain events for a specified aggregate, within a given version range. Each fetched event is then transformed from its storage format into its actual domain event type using the DomainEventHelper.ConstructDomainEvent method.

public async Task<IReadOnlyCollection<IDomainEvent<TAggregateId>>> LoadAsync<TAggregateId>(TAggregateId aggregateRootId, string aggregateName, int fromVersion, int toVersion)
{
    Guard.Against.Negative(fromVersion, nameof(fromVersion));
    Guard.Against.Negative(toVersion, nameof(toVersion));
    if (fromVersion > toVersion)
    {
        throw new ArgumentException($"{nameof(fromVersion)} cannot be greater than {nameof(toVersion)}");
    }

    IQueryable<EventEntity> events = _events.Where(e => e.AggregateId == aggregateRootId.ToString() && e.AggregateName == aggregateName && e.Version >= fromVersion && e.Version <= toVersion).OrderBy(de => de.Version);
    var domainEvents = new List<IDomainEvent<TAggregateId>>();

    //get events
    foreach (var @event in events)
    {
        var domainEvent = DomainEventHelper.ConstructDomainEvent<TAggregateId>(@event.Data, @event.AssemblyTypeName);
        domainEvents.Add(domainEvent);
    }

    return domainEvents.AsReadOnly();
}

Saving Domain Events

EFEventStore provides two SaveAsync methods: one for saving a collection of domain events and another for saving a single event. Both methods create corresponding EventEntity instances for each domain event and add them to the EventEntity DbSet. The changes are then persisted to the database using the SaveChangesAsync method.

public async Task SaveAsync<TAggregateId>(string aggregateName, int expectedVersion, IEnumerable<IDomainEvent<TAggregateId>> domainEvents)
{
    foreach (var domainEvent in domainEvents)
    {
        EventEntity eventEntity = ConstructEventEntity(domainEvent, expectedVersion, aggregateName);
        await _events.AddAsync(eventEntity);
    }
    await _context.SaveChangesAsync();
}

public async Task SaveAsync<TAggregateId>(string aggregateName, int expectedVersion, IDomainEvent<TAggregateId> domainEvent)
{

    EventEntity eventEntity = ConstructEventEntity(domainEvent, expectedVersion, aggregateName);
    await _events.AddAsync(eventEntity);
    await _context.SaveChangesAsync();
}

Event Entity Construction

To assist in saving domain events, the private method ConstructEventEntity is used. This method constructs an EventEntity instance from a given domain event. The method also checks for potential concurrency issues by verifying the version of the incoming domain event against the expected version. The domain event is serialized into a string format for storage, and additional metadata, like the event’s type, is captured for future deserialization.

private EventEntity ConstructEventEntity<TAggregateId>(IDomainEvent<TAggregateId> domainEvent, int expectedVersion, string aggregateName)
{
    if (domainEvent.AggregateVersion > expectedVersion)
        throw new EventStoreException($"Concurrency issue detected when saving events. Event found with version {domainEvent.AggregateVersion} which is larger than maximum expected version {expectedVersion}");

    Type domainEventType = domainEvent.GetType();
    return new EventEntity()
    {
        Id = domainEvent.EventId,
        AggregateId = domainEvent.AggregateId.ToString(),
        AggregateName = aggregateName,
        Name = domainEventType.Name,
        AssemblyTypeName = domainEventType.AssemblyQualifiedName,
        Data = JsonConvert.SerializeObject(domainEvent),
        Version = domainEvent.AggregateVersion,
        CreatedAt = DateTime.UtcNow //duplicate. save or lose??
    };
}

The Snapshot Provider

As our system evolves and the number of events increases, snapshots become essential for performance optimization. The EFEventStoreSnapshotProvider class gives us the capability to save the current state of an aggregate, allowing us to avoid reapplying a large number of events. Through this service, we can persist these snapshots and retrieve them when needed. The full implementation is shown below:

using Microsoft.EntityFrameworkCore;
using Newtonsoft.Json;
using CH.EventStore.Abstractions;
using CH.Domain.Abstractions;
using CH.EventStore.EntityFramework.Entities;
using System.Threading.Tasks;
using System;
using System.Linq;

namespace CH.EventStore.EntityFramework
{
    /// <summary>
    /// Implementation of <see cref="IEventStoreSnapshotProvider"/> using Entity Framework
    /// </summary>
    internal class EFEventStoreSnapshotProvider : IEventStoreSnapshotProvider
    {
        private readonly EventStoreDbContext _context;
        private readonly DbSet<AggregateSnapshotEntity> _snapshots;
        private readonly JsonSerializerSettings _jsonSerializerSettings = new JsonSerializerSettings { ContractResolver = new PrivateSetterContractResolver() };

        public EFEventStoreSnapshotProvider(EventStoreDbContext context)
        {
            _context = context;
            _snapshots = context.Set<AggregateSnapshotEntity>();
        }

        public async Task<T> GetAggregateFromSnapshotAsync<T, TAggregateId>(TAggregateId aggregateId, string aggregateName) where T : class, IAggregateRoot<TAggregateId>
        {
            AggregateSnapshotEntity entity = await GetLatestSnapshotAsync(aggregateId, aggregateName);
            if (entity == null)
                return default;
            T aggregate = JsonConvert.DeserializeObject<T>(entity.Data, _jsonSerializerSettings);
            aggregate.ClearUncommittedEvents(); //to remove constructor creation event
            return aggregate;
        }

        public async Task SaveSnapshotAsync<T, TId>(T aggregate, Guid lastEventId) where T : class, IAggregateRoot<TId>
        {
            AggregateSnapshotEntity newSnapshot = new AggregateSnapshotEntity()
            {
                Data = JsonConvert.SerializeObject(aggregate),
                AggregateId = aggregate.Id.ToString(),
                LastAggregateVersion = aggregate.Version,
                AggregateName = typeof(T).Name,
                LastEventId = lastEventId
            };
            _snapshots.Add(newSnapshot);
            await _context.SaveChangesAsync();
        }

        private Task<AggregateSnapshotEntity> GetLatestSnapshotAsync<TAggregateId>(TAggregateId aggregateId, string aggregateName)
        {
            return _snapshots.Where(snap => snap.AggregateId == aggregateId.ToString() && snap.AggregateName == aggregateName).OrderByDescending(a => a.LastAggregateVersion).FirstOrDefaultAsync();
        }
    }
}

The Retroactive Events service

The EFRetroactiveEventsService is responsible for the critical task of applying retroactive events to an event stream. Using this service, we can correct or enhance an existing event stream by interleaving or replacing events that may have occurred out-of-order, were rejected, or later identified as incorrect.

Branch points

In event-sourced systems, once an event is stored, it is immutable; it cannot be changed. However, there are times when you might discover that an event was incorrect, or perhaps you wish to insert additional events in a specific position within the event stream. That’s where branch points come into play.

The BranchPointEntity class is a representation of such moments in the event stream where alterations are needed.

public class BranchPointEntity : DataEntityBase<int>
{
    /// <summary>
    /// Branch point indicative name
    /// </summary>
    public string Name { get; set; }

    /// <summary>
    /// FK for the Event Entity
    /// </summary>
    public Guid EventId { get; set; }

    /// <summary>
    /// The type of the branch point
    /// </summary>
    public BranchPointTypeEnum Type { get; set; }

    /// <summary>
    /// Navigation property of the event
    /// </summary>
    public virtual EventEntity Event { get; set; }

    public virtual ICollection<RetroactiveEventEntity> RetroactiveEvents { get; set; }
}

The properties of this BranchPointEntity are described below:

Name: This name helps in identifying or describing the purpose or reason for the branch point.
EventId: This is the foreign key that relates the branch point to a specific event in the event stream. It pinpoints the location in the event stream where retroactive changes need to be made.
Type (BranchPointTypeEnum): This enumeration value represents the nature of the branch point. There can be several types, such as:
- OutOfOrder: Indicates that events should be interleaved within the existing stream.
- Incorrect: Indicates that events should be added as a replacement of the linked event defined in the branch point.
- Rejected: Indicates that the event is not supposed to be part of the event stream.
Event (Navigation Property): This is the linked event in the event stream associated with the branch point.
RetroactiveEvents: It’s a collection of events that should be applied when this branch point is hit during the processing of the event stream. These are the events that will replace, precede, or follow the original event based on the branch point’s type.

Applying retroactive events to stream

The ApplyRetroactiveEventsToStream method is a central piece in our implementation of retroactive events within the event-sourced system. It takes in an event stream and returns a potentially modified stream by applying the branch points, making it an essential part of the retroactivity logic. Lets describe what happens in here in more detail:

Fetch Branch Points: We start by querying all the branch points that match events in the provided event stream.
Sequential Stream Processing: For each event in the input stream (processed in ascending order of their aggregate version):
- We check if there’s an associated branch point for the event.
- If a branch point exists, based on the type of the branch point (OutOfOrder, Incorrect, Rejected), we apply the necessary retroactive events from the branch point into the stream. This could mean adding new events, replacing existing ones, or even skipping certain events.
- If no branch point exists for the event, the event is added to the new stream unchanged.
Return New Stream: After processing all events, the method returns a potentially modified event stream.

It is important in event-sourcing implementations, especially in the context of retroactive changes, to remain faithful to two principles: immutability and maintaining the order of events. As you’ll notice in the implementation, the original event stream remains unchanged and a potential new stream with retroactive changes is created and returned. Also, it’s important to process the input stream in the correct order (i.e., ascending order of aggregate version) to ensure the retroactive events are injected at the right places.

Putting it all together

We’ve been discussing different parts of this architecture. Let’s take a moment to explore the synthesis of these elements, captured in our custom event-sourcing repository, ESRepository.

The ESRepository class serves as a tailored repository for event-sourced entities. It’s built upon the concept of aggregate roots, represented by the IAggregateRoot abstraction. For those who’ve been following along, you’ll recall that we touched on the IAggregateRoot abstraction in a previous post. It forms the cornerstone of Domain-Driven Design (DDD) and the event sourcing patterns, encapsulating the business logic and ensuring changes are made in a consistent and valid way.

internal class ESRepository<T, TId> : IESRepository<T, TId> where T : class, IAggregateRoot<TId>
{
    private readonly ILogger<ESRepository<T, TId>> _logger;
    private readonly IEventStore _eventStore;
    private readonly IEventStoreSnapshotProvider _snapshotService;
    private readonly IRetroactiveEventsService _retroEventsService;
    private const int SNAPSHOT_FREQUENCY = 50;

    public ESRepository(ILogger<ESRepository<T, TId>> logger, IEventStore eventStore, IEventStoreSnapshotProvider snapshotProvider, IRetroactiveEventsService retroEventsService)
    {
        _logger = logger;
        _eventStore = eventStore;
        _snapshotService = snapshotProvider;
        _retroEventsService = retroEventsService;
    }

    public async Task<T> GetByIdAsync(TId id)
    {
        try
        {
            T aggregate = CreateEmptyAggregate();
            string aggregateName = typeof(T).Name;
            int fromVersion = 0;

            T snapshotAggregate = await _snapshotService.GetAggregateFromSnapshotAsync<T, TId>(id, aggregateName);
            if (snapshotAggregate != default)
            {
                aggregate = snapshotAggregate;
                fromVersion = snapshotAggregate.Version + 1;
            }

            var eventsForAggregate = await _eventStore.LoadAsync<TId>(id, aggregateName, fromVersion, int.MaxValue);

            //if no events are found, return default
            if (!eventsForAggregate.Any() && snapshotAggregate == default) //if no events or snapshot is found
                throw new EventStoreAggregateNotFoundException($"Aggregate {aggregateName} with id {id} not found");

            eventsForAggregate = _retroEventsService.ApplyRetroactiveEventsToStream<T, TId>(eventsForAggregate);

            foreach (var @event in eventsForAggregate)
            {
                aggregate.ApplyEvent(@event, @event.AggregateVersion);
            }

            if (aggregate.IsDeleted)
                throw new EventStoreAggregateNotFoundException($"Aggregate {aggregateName} with id {id} not found");

            return aggregate;
        }
        catch (Exception ex)
        {
            _logger.LogError($"Error occured while retrieving from event source repository. Exception: {ex}");
            throw;
        }
    }

    public async Task SaveAsync(T aggregate)
    {
        try
        {
            IAggregateRoot<TId> aggregatePersistence = aggregate;
            string aggregateName = typeof(T).Name;
            var uncommittedEvents = aggregate.GetUncommittedEvents();

            if (!uncommittedEvents.Any())
            {
                return;
            }

            Guid lastEventId = uncommittedEvents.Last().EventId;

            await _eventStore.SaveAsync(aggregateName, aggregate.Version, uncommittedEvents);
            if (ShouldSnapshot(aggregate.Version, uncommittedEvents.Count()))
            {
                await _snapshotService.SaveSnapshotAsync<T, TId>(aggregate, lastEventId);
            }
            aggregatePersistence.ClearUncommittedEvents();
        }
        catch (Exception ex)
        {
            _logger.LogError($"Error occured while saving aggregate. Exception: {ex}");
            throw;
        }
    }

    private T CreateEmptyAggregate()
    {
        return (T)typeof(T).GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, null, Array.Empty<Type>(), Array.Empty<ParameterModifier>()).Invoke(Array.Empty<object>());
    }

    private bool ShouldSnapshot(int aggregateVersion, int numberOfeventsToCommit)
    {
        //Every N events we save a snapshot
        return ((aggregateVersion >= SNAPSHOT_FREQUENCY) &&
            (
                (numberOfeventsToCommit >= SNAPSHOT_FREQUENCY) ||
                (aggregateVersion % SNAPSHOT_FREQUENCY < numberOfeventsToCommit) ||
                (aggregateVersion % SNAPSHOT_FREQUENCY == 0)
            )
        );
    }
}

This repository provides a seamless interface to interact with event-sourced entities by orchestrating operations with the Event Store, Snapshot Service, and the Retroactive Events Service. It facilitates fetching the aggregate’s current state by replaying events and possibly leveraging snapshots for efficiency. Additionally, it handles the persistence of new domain events and decides when to take snapshots based on the number of events occurred previously.

Wrapping up

Event Sourcing is a profound pattern that can offer immense value to applications, especially when dealing with complex domain logic. In this exploration, we’ve touched upon the various intricacies and components that contribute to a holistic event-sourcing architecture.

To facilitate ease of integration and modularity, the abstractions have been packaged into one Nuget package, while the Entity Framework Core implementations are encapsulated in another separate package. For those eager to delve deeper into the inner workings, or perhaps even contribute, the source code is available in the repository.

Resources

Follow some of the links below if you are interested to know more about event-sourcing, its pros and cons, and when or why you should (or shouldn’t) use it.

Martin Fowler on Event Sourcing: A comprehensive introduction to the event sourcing pattern from one of the industry’s leading figures. Read here

Event Sourcing Pattern – Microsoft Azure: Detailed insights into the pattern, especially in the context of cloud solutions. Check it out

Greg Young – The art of destroying software: A must-watch talk for anyone diving into event sourcing, where Greg Young elaborates on the importance of being able to rebuild your system at any point in time. Watch the talk

Event Store: An open-source, functional database that exclusively uses the event sourcing pattern. It provides a good reference for those looking to see event sourcing in action. Visit their website

Domain-Driven Design: While not exclusively about event sourcing, Eric Evans’ book on Domain-Driven Design touches on patterns and practices that align closely with event sourcing. A recommended read for anyone delving into domain modeling. Find the book here

Event Sourcing Made Simple: A blog post that breaks down the complexities of event sourcing into digestible bits. Read the post

Event Sourcing Pattern – Microservices.io: A concise breakdown of the event sourcing pattern in the context of microservices architecture. The page offers clear diagrams and explanations of key concepts. Dive in here

The Value of Unit Testing in Software Development

thecodewrapper — Tue, 17 Oct 2023 13:06:38 +0000

In this post we’ll explore the importance and need for unit testing in software development. While other articles focus on the practical aspects of testing, such as how to write effective test cases and how to use testing tools, we’ll approach this topic from a different perspective. We will delve into the philosophical significance of testing and share personal experiences that highlight the importance of this crucial aspect of software development.

A practical guide on how to properly write unit tests and the various tools to use is something I’ll maybe cover in another article. This is about the value of unit testing as such, and why you should make it a habit to have them.

Always think ahead

Personally, I’m not a very laid back person. I like to think things through. What I always say, and this applies to all things in my life, not just coding, is “always have a contingency plan”. If you think of all (or as many possible) outcomes a given situation may come to, then you can plan for them, and that is precious. One of my favorite quotes is “If you fail to plan, you plan to fail”. I like to sleep peacefully at nights, so I try to plan for as much as possible.

A few years ago, I worked for a company (or two) which did not write any unit tests. We, the developers just focused on writing our code, doing some manual testing and just pushing it through. Essentially the only testing that was happening was by a QA team, or by the developers themselves. This meant that tasks finished quickly, but resulted in bugs in production or if we were lucky, bugs were picked during QA testing and returned back to us for fixing.

Time saver

Now, let me clear something up. Unit testing does not replace manual developer testing. Both are equally important and time should be allocated for both of them. What unit tests do, is to diminish guess-work. This means that if something goes wrong, or a bug comes up and something isn’t working as it should, unit tests help with swiftly identifying the part of the code that has the issue. Also, by testing segments of your code as a unit, helps with identifying errors early in the development process, which saves valuable time.

Avoid code complexity

Another byproduct of not having unit tests, is bad code. Whenever a bug is fixed in the absence of unit tests, the code tends to become more complex. When you write unit tests, you are forced to think about how your code should behave in isolation. This means you have to break down your code into smaller, more manageable units, which can help avoid the creation of large, complex code blocks.

Unit tests can also help ensure that code changes do not create new complexity. Whenever a developer makes a change to the code, they can run the unit tests to ensure that the changes have not introduced any new bugs or unintended consequences. This helps ensure that the code remains simple and straightforward.

A matter of life and death

Unit testing is important for several reasons, including identifying and fixing bugs early in the development cycle, improving code quality, and increasing confidence in the software being developed. However, perhaps one of the most compelling reasons for the importance of unit testing is the potential consequences of not doing it.

The 1992 incident in London is a prime example of what can happen when software is not properly tested. In that year, London’s brand new computer-aided ambulance-dispatch system suffered a catastrophic failure due to a software error. The system was supposed to help ambulance crews respond to emergencies more efficiently, but instead, it caused chaos and confusion.

A software error caused the dispatch system to fail, resulting in long delays and increased response times for emergency calls. In some cases, patients died while waiting for an ambulance to arrive. The failure of the system had far-reaching consequences and led to public outrage and an investigation into the cause of the failure.

The cause of the failure was eventually traced back to a software error that had not been caught during testing. The failure of the ambulance dispatch system was a tragic reminder of the importance of proper testing and quality assurance in software development.

Had the software been properly tested, the error would have been identified and fixed before the system went live. The tragic consequences of the London ambulance dispatch failure highlight the critical importance of unit testing and quality assurance in software development.

This article provides more details about the incident and its aftermath, including the investigation into the cause of the failure and the lessons learned from the tragedy.

Conclusion

Unit testing is an essential practice in software development that should not be overlooked. It can help identify and fix bugs early in the development cycle, improve code quality, and increase confidence in the software being developed. Moreover, it can help prevent catastrophic failures like the one that occurred with London’s ambulance dispatch system in 1992.

By prioritizing unit testing, developers can ensure that the software they create is reliable, secure, and ethical, and that it meets the needs of users and society as a whole. In short, the value of unit testing in software development cannot be understated, and it is essential for creating software that is of the highest quality.

How to: Send Microsoft Teams self-message using Graph SDK

thecodewrapper — Sun, 19 Mar 2023 15:43:32 +0000

Introduction

Microsoft Teams has become an indispensable tool for businesses and organizations to communicate and collaborate. Sometimes, you might want to send a message to yourself as a reminder or to keep track of important information.In this tutorial, I will demonstrate how to send Microsoft Teams self-message using Graph SDK by creating a simple console application in .NET 6.

Requirements

For this you need the following:

A Microsoft Teams account with a valid subscription.
Microsoft Graph SDK installed in your development environment.
A registered app in Azure Active Directory with required permissions.
.NET Core installed on your development environment.

Note: When registering your application in Azure AD, you need to add a redirect URI with the following properties:

Platform: Public client/native (Mobile & Desktop)
Value: http://localhost

This is needed when authenticating using an interactive browser.

Step 1: Create a new .NET Core console application

Open a command prompt or terminal, and create a new .NET Core console application using the following command:

dotnet new console --name TeamsSelfMessage

Navigate to the newly created project folder:

cd TeamsSelfMessage

Step 2: Add necessary packages

To send a self-message on Microsoft Teams using the Graph SDK, first, install the necessary packages:

dotnet add package Microsoft.Graph
dotnet add package Microsoft.Graph.Core
dotnet add package Microsoft.Identity.Client
dotnet add package Microsoft.Extensions.Configuration.Json
dotnet add package Azure.Identity

Step 3: Configure the app settings

Add a new file to the project named appsettings.json. Make sure you configure the Build Action to Content and the Copy to Output Directory to Copy Always.

{
  "appId": "YOUR_APP_ID",
  "tenantId": "YOUR_TENANT_ID",
}

Replace YOUR_APP_ID and YOUR_TENANT_ID with your actual app registration details from Azure Active Directory.

Step 4: Set up the Graph SDK and authenticate

Open the Program.cs file and add the following using statements:

using System;
using System.IO;
using System.Threading.Tasks;
using Azure.Identity;
using Microsoft.Extensions.Configuration;
using Microsoft.Graph;
using Microsoft.Graph.Models;

Add the following field to hold the scopes for the authentication of the GraphServiceClient:

private static string[] _graphScopes = new[] { "User.Read", "ChatMessage.Send", "Chat.ReadWrite" };

Also add the following field which denotes the chat with yourself:

private const string SELF_CHAT_ID = "48:notes";

Add the following method to authenticate and initialize the Graph SDK:

private static async Task<GraphServiceClient> GetGraphClient(IConfiguration configuration)
{
    var interactiveBrowserCredentialOptions = new InteractiveBrowserCredentialOptions
    {
        ClientId = configuration["appId"],
        TenantId = configuration["tenantId"]
    };
    var tokenCredential = new InteractiveBrowserCredential(interactiveBrowserCredentialOptions);

    var graphClient = new GraphServiceClient(tokenCredential, _graphScopes);
    _ = await graphClient.Me.GetAsync(); //trigger login
    return graphClient;
}

Step 5: Implement the self-message functionality

With the Graph SDK set up, we can now implement the functionality to send a self-message in Microsoft Teams. Add the following method to send a message to yourself:

private static async Task<ChatMessage> SendMessageAsync(GraphServiceClient graphClient, string messageContent)
{
    var message = new ChatMessage
    {
        Body = new ItemBody
        {
            ContentType = BodyType.Html,
            Content = messageContent
        }
    };

    return await graphClient.Me.Chats[SELF_CHAT_ID].Messages.PostAsync(message);
}

Step 6: Call the self-message methods from Main

Modify the Main method to call the self-message method as follows:

public static async Task Main(string[] args)
{
    var configuration = new ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .Build();

    var graphClient = await GetGraphClient(configuration);

    string messageContent = "This is a message to myself!";
    ChatMessage sentMessage = await SendMessageAsync(graphClient, messageContent);
    Console.WriteLine($"Message sent with ID: {sentMessage.Id}");

    Console.WriteLine("Press any key to exit...");
    Console.ReadKey();
}

Now, you can run the console application using the following command:

dotnet run

Conclusion

The console application will prompt you for authentication and send a message to yourself on Microsoft Teams. You can check your Teams client to see the message.

That’s it! You have successfully implemented self-messaging functionality in a .NET Core console application using the Microsoft Graph SDK.

For completeness, here is the full code for the Program.cs below:

using System;
using System.IO;
using System.Threading.Tasks;
using Azure.Identity;
using Microsoft.Extensions.Configuration;
using Microsoft.Graph;
using Microsoft.Graph.Models;

namespace TeamsSelfMessage
{
    class Program
    {
        private static string[] _graphScopes = new[] { "User.Read", "ChatMessage.Send", "Chat.ReadWrite" };
        private const string SELF_CHAT_ID = "48:notes";

        public static async Task Main(string[] args)
        {
            var configuration = new ConfigurationBuilder()
                .SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
                .Build();

            var graphClient = await GetGraphClient(configuration);

            string messageContent = "This is a message to myself!";
            ChatMessage sentMessage = await SendMessageAsync(graphClient, messageContent);
            Console.WriteLine($"Message sent with ID: {sentMessage.Id}");

            Console.WriteLine("Press any key to exit...");
            Console.ReadKey();
        }

        private static async Task<GraphServiceClient> GetGraphClient(IConfiguration configuration)
        {
            var interactiveBrowserCredentialOptions = new InteractiveBrowserCredentialOptions
            {
                ClientId = configuration["appId"],
                TenantId = configuration["tenantId"]
            };
            var tokenCredential = new InteractiveBrowserCredential(interactiveBrowserCredentialOptions);

            var graphClient = new GraphServiceClient(tokenCredential, _graphScopes);
            _ = await graphClient.Me.GetAsync(); //trigger login
            return graphClient;
        }

        private static async Task<ChatMessage> SendMessageAsync(GraphServiceClient graphClient, string messageContent)
        {
            var message = new ChatMessage
            {
                Body = new ItemBody
                {
                    ContentType = BodyType.Html,
                    Content = messageContent
                }
            };

            return await graphClient.Me.Chats[SELF_CHAT_ID].Messages.PostAsync(message);
        }
    }
}

You can also find the GitHub repository with the complete solution here.

Designing the domain model to support multiple persistence methods

thecodewrapper — Sun, 19 Mar 2023 15:30:27 +0000

Introduction

This is a continuation of my earlier post Implementing a Clean Architecture in ASP.NET Core 6, so if you haven’t read that yet, I suggest you do as it will provide a little more context, although it is not necessary to follow along.

As mentioned in the previous post, I wanted to allow the use of a traditional state-oriented CRUD model for persistence, and at the same time have the ability to switch to an event sourcing method, or even use both side-by-side. So in this post, we’ll take a look at how to design our domain model so we can use both event-sourcing and a state persistence model together, or interchangeably.

One key assumption for this is that we’ll be using EF Core with SQL Server for our relational persistence method.

The goal

The main goal was to have domain entities within the project be able to be persisted either using a relational model or using event sourcing, or even both together without changing the underlying implementation of the domain entity itself. In that, I wanted to keep the structure of the core aligned with Domain-Driven Design practices.

To make this work, it naturally had to be based on some form of event mechanism. In this case, domain events seems quite a good fit. To learn what domain events are and how they fit into the whole domain-driven design approach, take a look at some of the resources at the end of this post.

Through my research prior to starting this journey, I found that there are quite a few ways domain events can be implemented. I’ve come to realize that there isn’t a “better” way to do this, the “best” way is what fits in the overall architecture and the purpose for which you want to utilize domain events.

For this to be a viable solution, I’ve set out to achieve the following low-level goals:

Encapsulate the handling logic of the event within the aggregate itself
Handle the events in such a way that if event sourcing is used, the playback of events would allow the aggregate object to build itself into its latest state
Have compile-time safety such that the event handlers are guaranteed to be implemented

Why domain events?

I took the approach of having functions in the aggregates which contain some logic to only raise an event, and have that event handler internally, within the aggregate, perform any changes to the aggregate. This is because it serves the purpose of event-sourcing and non-event sourcing implementations at the same time; it caters to the reconstruction of the aggregate’s state from the event stream.

Once again, I’ve looked into what is out there in terms of domain event implementations. Below some articles for domain events:

Initial approach

My initial approach to handle and apply domain events was to have internal functions called Apply inside the aggregates. Each function would take the event object its supposed to handle and do whatever work they are supposed to do.

Whenever we would like an event to fire, we’ll call the RaiseEvent function which is inherited by the AggregateRootBase class. The RaiseEvent function does some versioning related work and subsequently calls into the ApplyEvent function (part of the IAggregateRoot interface).

In turn, this dynamically calls the appropriate Apply function on the aggregate, according to the type of the event passed in. The implementation of RaiseEvent and the initial implementation of the ApplyEvent function in the AggregateRootBase looked like this:

protected void RaiseEvent<TEvent>(TEvent @event)
            where TEvent : DomainEventBase<TId> {
            int version = Version + 1;
            IDomainEvent<TId> eventWithAggregate = @event.WithAggregate(
                Equals(Id, default(TId)) ? @event.AggregateId : Id,
                version);

            ((IAggregateRoot<TId>)this).ApplyEvent(eventWithAggregate, version);
            _uncommittedEvents.Add(eventWithAggregate);
        }

void IAggregateRoot<TId>.ApplyEvent(IDomainEvent<TId> @event, int version) {
            if (!_uncommittedEvents.Any(x => Equals(x.EventId, @event.EventId))) {
                ((dynamic)this).Apply((dynamic)@event);
                Version = version;
            }
        }

Below an example of how this would be raised by the aggregate:

public Order(string trackingNumber) {
            RaiseEvent(new OrderCreatedEvent(trackingNumber));
        }

internal void Apply(OrderCreatedEvent @event) {
            Id = @event.AggregateId;
            TrackingNumber = @event.TrackingNumber;
        }

Now, this has the benefit of good encapsulation by keeping the handling of the event internal, not exposed to the outside world. However, it does not give the benefit of compile-time checking in terms of actually having the implementation to handle the event in place. This would show up at runtime if I accidentally forgot to write the Apply function for a given event. We could argue that this is not so much of an issue, however being the picky person that I am, I couldn’t allow this 🙂

Therefore, i tried a different approach.

Second attempt

With this second approach, aggregates implement the IDomainEventHandler generic interface, which has just one function to handle the event.

internal interface IDomainEventHandler<T> where T: IDomainEvent
    {
        internal void Apply(T @event);
    }

The AggregateRootBase contains the code which applies the actual event. This uses reflection to invoke the aggregate’s Apply function for the particular domain event type, implemented via the interface internally.

void IAggregateRoot<TId>.ApplyEvent(IDomainEvent<TId> @event, int version) {
            if (!_uncommittedEvents.Any(x => Equals(x.EventId, @event.EventId))) {
                var handlerType = GetType()
                    .GetInterfaces()
                    .Single(i => i.GetGenericTypeDefinition() == typeof(IDomainEventHandler<>) && i.GetGenericArguments()[0] == @event.GetType());
                var handlerMethod = handlerType.GetTypeInfo().GetDeclaredMethod(nameof(IDomainEventHandler<IDomainEvent>.Apply));
                handlerMethod.Invoke(this, new object[] { @event });
            }
            Version = version;
        }

So now, the way this would be handled by the aggregate turns into this:

public Order(string trackingNumber) {
            RaiseEvent(new OrderCreatedEvent(trackingNumber));
        }

void IDomainEventHandler<OrderCreatedEvent>.Apply(OrderCreatedEvent @event) {
            Id = @event.AggregateId;
            TrackingNumber = @event.TrackingNumber;
        }

There are a couple of reasons I went in this direction.

First, I wanted to keep the implementation of the handler inside the aggregate itself, and also provide compile-time safety in having to implement the IDomainEventHandler interface.

Secondly, I wanted to have the handler implementations access modifier be internal, since these handler implementations are contained within the domain entities, which themselves are visible to all outer layers. I don’t like having the handling of an event be visible to the outside world.

I would say this approach provides good encapsulation in regards to raising and handling domain events, with the downside of been slower due to reflection, although the performance impact is fairly negligible.

Final result

Having said that, there is an issue with the above approach as well. The issue here is that any exception thrown within the IDomainEventHandler implementation, actually bubbles up as a TargetInvocationException, which is an exception thrown when methods are invoked using reflection. This type of exception wraps the original exception in the InnerException property. Obviously this reduces testability, and is therefore not acceptable.

To avoid this, I wrapped the invocation around a try/catch block which will re-throw the inner exception. So the final implementation looks like this:

void IAggregateRoot<TId>.ApplyEvent(IDomainEvent<TId> @event, int version) {
            if (!_uncommittedEvents.Any(x => Equals(x.EventId, @event.EventId))) {
                try {
                    var handlerType = GetType()
                    .GetInterfaces()
                    .Single(i => i.GetGenericTypeDefinition() == typeof(IDomainEventHandler<>) && i.GetGenericArguments()[0] == @event.GetType());
                    var handlerMethod = handlerType.GetTypeInfo().GetDeclaredMethod(nameof(IDomainEventHandler<IDomainEvent>.Apply));
                    handlerMethod.Invoke(this, new object[] { @event });
                }
                catch (TargetInvocationException ex) {
                    throw ex.InnerException;
                }
            }
            Version = version;
        }

For now, I can make my peace with this try/catch block, at least until any significant performance issues arise. I may look into doing some performance testing to see how that goes in the future.

Below the entire AggregateRootBase class, as it stands now:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;

namespace CH.CleanArchitecture.Core.Domain
{
    public abstract class AggregateRootBase<TId> : IAggregateRoot<TId>
    {
        public const int NewAggregateVersion = -1;

        private readonly ICollection<IDomainEvent<TId>> _uncommittedEvents = new LinkedList<IDomainEvent<TId>>();

        /// <summary>
        /// The aggregate root Id
        /// </summary>
        public TId Id { get; protected set; }

        /// <summary>
        /// The aggregate root current version
        /// </summary>
        public int Version { get; private set; } = NewAggregateVersion;

        /// <summary>
        /// Indicates whether this aggregate is logically deleted
        /// </summary>
        public bool IsDeleted { get; private set; }

        void IAggregateRoot<TId>.ApplyEvent(IDomainEvent<TId> @event, int version) {
            if (!_uncommittedEvents.Any(x => Equals(x.EventId, @event.EventId))) {
                try {
                    InvokeHandler(@event);
                    Version = version;
                }
                catch (TargetInvocationException ex) {
                    throw ex.InnerException;
                }
            }
            Version = version;
        }

        void IAggregateRoot<TId>.ClearUncommittedEvents() {
            _uncommittedEvents.Clear();
        }

        IEnumerable<IDomainEvent<TId>> IAggregateRoot<TId>.GetUncommittedEvents() {
            return _uncommittedEvents.AsEnumerable();
        }

        protected void MarkAsDeleted() {
            IsDeleted = true;
        }

        protected void RaiseEvent<TEvent>(TEvent @event)
            where TEvent : DomainEventBase<TId> {
            int version = Version + 1;
            IDomainEvent<TId> eventWithAggregate = @event.WithAggregate(
                Equals(Id, default(TId)) ? @event.AggregateId : Id,
                version);

            ((IAggregateRoot<TId>)this).ApplyEvent(eventWithAggregate, version);
            _uncommittedEvents.Add(eventWithAggregate);
        }

        private void InvokeHandler(IDomainEvent<TId> @event) {
            var handlerMethod = GetEventHandlerMethodInfo(@event);
            handlerMethod.Invoke(this, new object[] { @event });
        }

        private MethodInfo GetEventHandlerMethodInfo(IDomainEvent<TId> @event) {
            var handlerType = GetType()
                    .GetInterfaces()
                    .Single(i => i.GetGenericTypeDefinition() == typeof(IDomainEventHandler<>) && i.GetGenericArguments()[0] == @event.GetType());
            return handlerType.GetTypeInfo().GetDeclaredMethod(nameof(IDomainEventHandler<IDomainEvent>.Apply));
        }
    }
}

As always, any feedback on this is much appreciate so please feel free to let me know what you think of this approach.

Resources

To find out additional information about domain events, what they are, their benefits and how the fit into your design, follow one of the links below:

Why I “hate” optional parameters in C#

thecodewrapper — Fri, 11 Mar 2022 11:00:07 +0000

Let me start by saying that the title of this post is a little exaggerated in regards to how I feel about optional parameters. “Hate” is a strong word and I certainly don’t mean that optional parameters are a useless feature or that it is a bad practice to use them. It’s just that, I’ve rarely seen them used correctly and in almost all cases I see them being used, they bring more problems than solutions. After many long and painful debugging sessions, the sight of optional parameters in method declarations are accompanied by a despicable code smell the equivalent of a rotten egg, until proven otherwise. Allow me to elaborate and share my experiences.

What are they about?

Optional arguments, also known as default parameters (the most misleading AKA if I’ve ever heard one), were introduced in C# 4. Their intention was to provide a convenient and flexible way to omit function arguments for certain parameters whenever they are not required.

Optional does not mean Default

One of the biggest misuses of optional parameters is that of providing a default argument to a function. Although it is mandatory to provide a default value to an optional argument, it doesn’t mean that this feature should be used whenever you want to have some default value in a function. Specifying a default value is simply a requirement to use this feature, it is not the reason of it’s existence.

In fact, take a close look at the definition of optional arguments in Microsoft’s official C# Guide, and you’ll notice that there is nothing mentioned of using it for the purpose of passing a default value to a function.

Optional arguments are compile-time constants

There are quite a few issues that may arise when using optional arguments for the purpose of providing a default value to a function.

Optional arguments are compile-time constants, meaning that the default value is embedded at the caller side, not the callee. This may lead to unexpected results at the caller side. Consider the following segment of code where a function DoSomething is defined in a class called LibA:

public class LibA
{
   public string DoSomething(string optional = "FromLibA")
   {
       return optional;
   }
}

The above class exists in its own separate library. Now, consider the following code where the DoSomething function is consumed:

LibA libA = new LibA();
Console.Write(libA.DoSomething());

The output of the above will obviously be “FromLibA”. But now consider the scenario where a change is made in the LibA class, and the default value of the optional parameter is changed to something else. The above console output would still be “FromLibA”. In order for the change to “take” then both the LibA assembly and the consumer assembly need to be compiled.

Difference in polymorphic behavior through interfaces

Furthermore, there may be a difference between the optional values when using them through an interface function and when using them through a concrete implementation, if the default value definition does not match.

Consider the following example:

public interface IMyInterface
{
    string DoSomething(string optional = "FromInterface");
}

public class LibA : IMyInterface
{
    public string DoSomething(string optional = "FromLibA")
    {
        return optional;
    }
}

LibA caller = new LibA();
IMyInterface interfaceCaller = new LibA();

Console.WriteLine(caller.DoSomething());
Console.WriteLine(interfaceCaller.DoSomething());

The output of the above two statements will be different. In the case of calling the concrete class (caller) the output will be “FromLibA”, and in the latter it will be “FromInterface”. This can become particularly confusing in cases you are using dependency injection through interfaces because it is not clear which default value is being used.

Alternatives

If you need to have a default parameter which can be optionally overridden by the caller, there are plenty of alternatives:

Use function overloading with the parameter in question and have the caller decide if they want to provide a value for that parameter by calling the appropriate overload. If the original function instead of the overloaded one is used, then the value for that parameter can be defined within the function body.
In case of multiple properties, create a dedicated type to hold those properties and use that in a function overload. This would allow you to easily extend the parameters in the future if needed.
Abstract away the default value so it is provided by another component or service. This is cleaner and decouples the actual value from the consumer.

Same-type parameter ambiguity

To add insult to injury, when you have an interface which specifies a default value for an optional parameter, you are allowed to ignore the parameter on a class that implements that interface. This can become a problem when your class implements multiple interfaces with functions which use the same number and type of parameters. In order to call the appropriate function you would need to call it through the interface.

When its OK to use them

To simplify the calling of class constructors, and other creational mechanism functions (i.e. factory) which have a long list of complex arguments, and to avoid having to create multiple convoluted overloads to cover all possible combinations. That’s strictly it. Notice that when I refer to a long list of arguments, I strictly mean that in the context of object creation, and even more so for class constructors.

If you ever find yourself at a point where you have multiple optional parameters for non-constructors or non-factory object creation functions, then your function is almost certainly doing too much, and you should refactor your code to break things down in smaller pieces (see SRP).

When you MUST use them

Almost never. There is literally no case (or at least I’ve never had a case in my years of coding) where I absolutely *had * to use optional arguments. As mentioned above, optional arguments is a convenience mechanism, it is not a critical language feature which you cannot live without.

As a rule of thumb

When coming across optional parameters in code reviews, always treat them as a code smell, until you’ve taken a closer look at the implementation and ensured that they are prudently used. This is even more important when coming across optional parameters in public functions.
Always prefer function overloading before optional parameters.
If an argument alters the flow of execution within a function, it should unequivocally not be optional.

A piece of “harsh” advice

Avoid using same-type optional parameters sequentially. If you see some piece of code which is doing that, refactor immediately.
Avoid using optional parameters in public functions altogether. Use them only for private/internal functions, and always with caution.
When specifying values for multiple optional arguments, make it a habit to use named arguments when calling a function.
Avoid using optional parameters in interface functions.

EF Core: Effectively decouple the data and domain model

thecodewrapper — Thu, 10 Feb 2022 10:38:56 +0000

Introduction

This is a continuation of my first post Implementing a Clean Architecture in ASP.NET Core 6, and describes the method I’ve used to achieve clear separation of data models and domain models. In this post, I’ll be expressing my views on the clear separation of persistence related models and business models and look into how we can effectively decouple the data and domain model when using EF Core.

First, domain model. Second, data model.

Over the last few EF Core iterations, there was a great deal of effort made to cater to tactical Domain-Driven Design practices when working with data entities (i.e. private field accessors). However, I personally feel that, even though we are now able to “combine” a data model and a domain model into one EF Core entity, the separation is still not entirely clear, and more often than not, you end up having persistence details “leaking” into your business/domain models (i.e. navigation properties). This can quickly lead to high-coupling of your behavioral model with the database domain.

So my rule is this: Data entities and any persistence-related code should be kept ONLY in the Infrastructure layer and never be allowed to leave! For this reason, domain layer repositories shall never return anything that resembles a data entity. Conceptually, data entities are objects which represent the data in some form of persistence. They have no business – pun intended 🙂 – in the domain layer. Data entities should be anemic POCO objects which are strictly a representation of whatever persistence method you are using. I don’t fancy the idea of having attributes relating to persistence or navigation properties in my domain model.

Additionally, you may need to persist some entities in your project, which are not conceptually part of your business domain layer. For example, application-wide configurations or tenant-specific parameters are very specific to the application itself and are best suited outside the application-independent business layer. However, from a management point-of-view you would still want to be able to add/remove/edit those entities from whatever presentation/UI medium you are using.

For both use-cases above, we’ll be using repositories to cover them.

Best of both worlds

The plan is to have two types of repositories, one that acts upon data entities and another that acts upon domain entities. For that, let first create a basic abstraction which both will depend on.

To achieve this, I have an IEntityRepository which operates on classes implementing the generic IEntity interface. Notice that the IEntityRepository also implements the IReadRepository and IWriteRepository generic interfaces.

Below the code for all aforementioned interfaces:

    public interface IEntity<TId>
    {
        TId Id { get; }
    }

    public interface IReadRepository<T>
    {
        bool Exists(Expression<Func<T, bool>> predicate);
        Task<bool> ExistsAsync(Expression<Func<T, bool>> predicate);
        IQueryable<T> GetAll();
        IQueryable<T> GetBy(Expression<Func<T, bool>> predicate);
        T GetFirst(Expression<Func<T, bool>> predicate);
        Task<T> GetFirstAsync(Expression<Func<T, bool>> predicate);
        T GetSingle(Expression<Func<T, bool>> predicate);
        Task<T> GetSingleAsync(Expression<Func<T, bool>> predicate);
    }

    public interface IWriteRepository<T> : IRepository
    {
        void Add(T entity);
        ValueTask AddAsync(T entity);
        void AddRange(IEnumerable<T> entities);
        Task AddRangeAsync(IEnumerable<T> entities);
        void Delete(T entity);
        void DeleteRange(IEnumerable<T> entities);
        void Update(T entity);
        void UpdateRange(IEnumerable<T> entities);
    }

    public interface IRepository
    {
        IUnitOfWork UnitOfWork { get; }
    }

    public interface IEntityRepository<T, TId> : 
        IReadRepository<T>, 
        IWriteRepository<T>
        where T : class, IEntity<TId>
    {
        T Find(TId id);
        Task<T> FindAsync(TId id);
    }

The data model repository

So far we have a pretty basic, albeit rich, abstraction for a repository. Moving forward, what we want to do is make the distinction between data entities and domain entities become clear. Firstly, we’ll create a basic implementation of a repository for retrieving data entities from our persistence store. This repository will operate on classes implementing the generic IDataEntity marker interface.

The code for the interface and concrete implementation of the data entities repository is shown below:

public interface IDataEntity<TId> : IEntity<TId>
{ }

internal class DataEntityRepository<T, TId> : IEntityRepository<T, TId> where T : class, IDataEntity<TId>
    {
        private readonly DbSet<T> _entities;
        private readonly ApplicationDbContext _context;
        public IUnitOfWork UnitOfWork => _context;

        public DataEntityRepository(ApplicationDbContext context)
        {
            _context = context ?? throw new ArgumentNullException(nameof(context));
            _entities = context.Set<T>();
        }

        public void Add(T entity)
        {
            Guard.Against.Null(entity, nameof(entity));
            _entities.Add(entity);
        }

        public async ValueTask AddAsync(T entity)
        {
            Guard.Against.Null(entity, nameof(entity));
            await _entities.AddAsync(entity);
        }

        public void AddRange(IEnumerable<T> entities)
        {
            _entities.AddRange(entities);
        }

        public Task AddRangeAsync(IEnumerable<T> entities)
        {
            return _entities.AddRangeAsync(entities);
        }

        public void Delete(T entity)
        {
            Guard.Against.Null(entity, nameof(entity));
            _entities.Remove(entity);
        }

        public void DeleteRange(IEnumerable<T> entities)
        {
            Guard.Against.Null(entities, nameof(entities));
            _entities.RemoveRange(entities);
        }

        public bool Exists(Expression<Func<T, bool>> predicate)
        {
            return _entities.Any(predicate);
        }

        public Task<bool> ExistsAsync(Expression<Func<T, bool>> predicate)
        {
            return _entities.AnyAsync(predicate);
        }

        public IQueryable<T> GetAll()
        {
            return GetEntities();
        }

        public IQueryable<T> GetBy(Expression<Func<T, bool>> predicate)
        {
            return GetEntities().Where(predicate);
        }

        public T GetFirst(Expression<Func<T, bool>> predicate)
        {
            return GetEntities().FirstOrDefault(predicate);
        }

        public async Task<T> GetFirstAsync(Expression<Func<T, bool>> predicate)
        {
            return await GetEntities().FirstOrDefaultAsync(predicate);
        }

        public T GetSingle(Expression<Func<T, bool>> predicate)
        {
            return GetEntities().SingleOrDefault(predicate);
        }

        public async Task<T> GetSingleAsync(Expression<Func<T, bool>> predicate)
        {
            return await GetEntities().SingleOrDefaultAsync(predicate);
        }

        public void Update(T entity)
        {
            Guard.Against.Null(entity, nameof(entity));
            _entities.Update(entity);
        }

        public void UpdateRange(IEnumerable<T> entities)
        {
            Guard.Against.Null(entities, nameof(entities));
            foreach (var entity in entities)
            {
                Update(entity);
            }
        }

        public T Find(TId id)
        {
            return _entities.Find(id);
        }

        public async Task<T> FindAsync(TId id)
        {
            return await _entities.FindAsync(id);
        }

        private IQueryable<T> GetEntities(bool asNoTracking = true)
        {
            if (asNoTracking)
                return _entities.AsNoTracking();
            return _entities;
        }
    }

The domain model repository

To handle retrieval and persistence actions of our domain entities, we’ll create a generic repository marker interface for aggregate root entities, called IAggregateRepository. This operates only on classes implementing the IAggregateRoot generic interface.

Below the code for the aforementioned interfaces:

public interface IAggregateRoot<TId> : IEntity<TId>
    {
        int Version { get; }
        void ApplyEvent(IDomainEvent<TId> @event, int version);
        IEnumerable<IDomainEvent<TId>> GetUncommittedEvents();
        void ClearUncommittedEvents();
        bool IsDeleted { get; }
    }

public interface IAggregateRepository<T, TId> : 
        IEntityRepository<T, TId> 
        where T : class, IAggregateRoot<TId>
    {
    }

The IAggregateRoot interface is pretty specific to the overall architecture, as you may notice from the few domain-event-related functions in there. For more information regarding this, take a look at my earlier post Designing the domain model to support multiple persistence methods. Despite that, the point of this is to distinguish between data entities and domain entities so you should adjust this interface properly to your needs.

You’ll notice that the IAggregateRepository interface also implements the IEntityRepository interface. Remember that the purpose of this aggregate repository is to solely act upon, and return, domain entities (specifically aggregate roots). In its generic abstract implementation, the aggregate repository (named EFRepository) uses AutoMapper to map between data entities and domain objects, and can directly operate on domain objects using projections, returning IQueryable. To do that, EFRepository makes use of a generic instance of IEntityRepository, which is registered in the DI container with an open generic type of DataEntityRepository.

The code for the concrete implementation of the abstract aggregate repository is shown below:

internal abstract class EFRepository<T, M, TId> : IAggregateRepository<T, TId>
        where T : class, IAggregateRoot<TId>
        where M : class, IDataEntity<TId>
    {
        private readonly IMapper _mapper;
        private readonly IEntityRepository<M, TId> _persistenceRepo;
        public IUnitOfWork UnitOfWork => _persistenceRepo.UnitOfWork;

        public EFRepository(IMapper mapper, IEntityRepository<M, TId> persistenceRepo) {
            _mapper = mapper;
            _persistenceRepo = persistenceRepo;
        }

        public virtual void Add(T entity) {
            Guard.Against.Null(entity, nameof(entity));

            var dataEntity = _mapper.Map<M>(entity);
            _persistenceRepo.Add(dataEntity);
        }

        public virtual async ValueTask AddAsync(T entity) {
            Guard.Against.Null(entity, nameof(entity));

            var dataEntity = _mapper.Map<M>(entity);
            await _persistenceRepo.AddAsync(dataEntity);
        }

        public virtual void AddRange(IEnumerable<T> entities) {
            var dataEntities = _mapper.Map<IEnumerable<M>>(entities);
            _persistenceRepo.AddRange(dataEntities);
        }

        public Task AddRangeAsync(IEnumerable<T> entities) {
            var dataEntities = _mapper.Map<IEnumerable<M>>(entities);
            return _persistenceRepo.AddRangeAsync(dataEntities);
        }

        public virtual void Delete(T entity) {
            Guard.Against.Null(entity, nameof(entity));

            var dataEntity = _mapper.Map<M>(entity);
            _persistenceRepo.Delete(dataEntity);
        }

        public virtual void DeleteRange(IEnumerable<T> entities) {
            Guard.Against.Null(entities, nameof(entities));

            var dataEntities = _mapper.Map<IEnumerable<M>>(entities);
            _persistenceRepo.DeleteRange(dataEntities);
        }

        public virtual bool Exists(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _persistenceRepo.Exists(expression);
        }

        public virtual Task<bool> ExistsAsync(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _persistenceRepo.ExistsAsync(expression);
        }

        public virtual IQueryable<T> GetAll() {
            return _mapper.ProjectTo<T>(_persistenceRepo.GetAll());
        }

        public virtual IQueryable<T> GetBy(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _mapper.ProjectTo<T>(_persistenceRepo.GetBy(expression));
        }

        public virtual T GetFirst(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _mapper.Map<T>(_persistenceRepo.GetFirst(expression));
        }

        public virtual async Task<T> GetFirstAsync(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _mapper.Map<T>(await _persistenceRepo.GetFirstAsync(expression));
        }

        public virtual T GetSingle(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _mapper.Map<T>(_persistenceRepo.GetSingle(expression));
        }

        public virtual async Task<T> GetSingleAsync(Expression<Func<T, bool>> predicate) {
            var expression = _mapper.Map<Expression<Func<M, bool>>>(predicate);
            return _mapper.Map<T>(await _persistenceRepo.GetSingleAsync(expression));
        }

        public virtual void Update(T entity) {
            Guard.Against.Null(entity, nameof(entity));

            var originalEntity = _persistenceRepo.Find(entity.Id);
            var updatedEntity = _mapper.Map(entity, originalEntity);
            _persistenceRepo.Update(updatedEntity);
        }

        public virtual async Task UpdateAsync(T entity) {
            Guard.Against.Null(entity, nameof(entity));

            var originalEntity = await _persistenceRepo.FindAsync(entity.Id);
            var updatedEntity = _mapper.Map(entity, originalEntity);
            _persistenceRepo.Update(updatedEntity);
        }


        public virtual void UpdateRange(IEnumerable<T> entities) {
            Guard.Against.Null(entities, nameof(entities));

            foreach (var entity in entities) {
                Update(entity);
            }
        }

        public T Find(TId id) {
            return _mapper.Map<T>(_persistenceRepo.Find(id));
        }

        public async Task<T> FindAsync(TId id) {
            return _mapper.Map<T>(await _persistenceRepo.FindAsync(id));
        }
    }

Things to remember

As mentioned earlier, all functions here take in a domain entity type and map that to their corresponding data entity type using AutoMapper. This is done for convenience, but keep in mind that the mapping might not always be straightforward between domain and data entities. You could adjust that for your own needs, either by working with AutoMapper custom value resolvers and type converters to do the proper mapping, or override the default implementation in-place to whatever you see fit.

Furthermore, it is a good practice to have a dedicated repository interface/implementation for each aggregate or aggregate root in your domain. Therefore, you can inherit from EFRepository to have a basic implementation of the repository functionality and override and/or add functions to cover your domain-specific needs. This is, after all, the purpose of this abstract repository.

Conclusion

As with everything described in the earlier related posts, this particular approach is not a one-size-fits-all approach. Admittedly, this setup has some complexity in its initial setup, and largely depends on the project whether it justifies the overhead. Personally, it has been the way to go for a couple of my recent projects and has worked quite well for me so far.

Feel free to drop a comment if you have any questions and let me know what you think of this approach.

Implementing a Clean Architecture in ASP.NET Core 6

thecodewrapper — Fri, 04 Feb 2022 07:54:27 +0000

Introduction

This post is the first part in a series of posts which describe my personal take on implementing a Clean Architecture with ASP.NET Core 6, and hopefully give you some ideas on how to go about building your own clean architecture.

This part is merely an overview of the overall architecture. More details on the internals and implementation will follow in separate posts.

Also, this post will not describe the concepts of a clean architecture in detail, nor will be an introduction to Domain-Driven Design or best practices. If you need to learn more about clean architecture concepts in detail, you can follow one of the links on the bottom of this post.

The intention of this design is to act as a starting point for building ASP.NET Core solutions. It is loosely-coupled, relies heavily on Dependency Inversion principle, and promotes Domain-Driven Design for organizing your core (although this is not forced). The goal for which I set out to do this, was to build a bare-bone, maintainable and extendable architecture.

Abstraction is key

My secondary goal was to abstract away concepts like domain events, CQRS and event sourcing from dependencies on specific implementations – or even other abstractions brought by some well-known packages – such as MediatR, MassTransit, EventStore etc.

Another particular thing I wanted to do with this, is to be able to combine and easily switch between relational (or non-relational for that matter) persistence methods and a streaming or event sourcing method without affecting any of the underlying architecture. I’ve seen quite a few implementations where the decision to use event sourcing for persistence is deeply rooted (or at least largely apparent) in how the core is organized. I wanted to avoid that and abstract it.

Although this is not a fully-fledged event store implementation (the default implementation is using Entity Framework Core with SQL Server to persist events, instead of something like an EventStore, which would be more technically appropriate), it serves the purpose of the aforementioned abstraction. The specifics of the actual implementation of event sourcing using Entity Framework Core, and the inclusion of snapshots and retroactive events, will be detailed in a future post.

Disclaimer

I do not claim that this design is in anyway better or cleaner than any others out there. This is simply what worked very well for me in several of my projects. Most software developers out there recognize that there is no single architecture which is best. The best architecture is the one that works well for you, your team and your type of project. This is by no means a production-ready solution, it is not a framework, it is merely a starting point.

Furthermore, this solution is not by all means complete in terms of features. There are several features which can be beneficial depending on the type of project you are building (caching, analytics etc.) which are not included at the time of this writing, but can be easily added if needed. I try to maintain this and add new features as much as time permits, so if you have any suggestions feel free to ask or contribute.

History

When I set out to build this bare-bone design I of course took input and advice from some very well-designed open-source architectures on GitHub:

https://github.com/ardalis/CleanArchitecture

https://github.com/dotnet-architecture/eShopOnContainers

https://github.com/jasontaylordev/CleanArchitecture

https://github.com/blazorhero/CleanArchitecture

There is great article from Uncle Bob (Robert C. Martin), who is a huge advocate of clean code and clean architecture practices: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html. His book Clean Architecture is also a great resource of valuable information about universal rules of software architecture, so I definitely recommend giving it a read if you are interested in building maintainable, loosely-coupled, long-lasting solutions.

There is also a great talk by Jason Taylor given at NDC Sydney in 2019 which talks about Clean Architecture in ASP.NET Core 3.0, in this video.

Technologies used

Features

The features of this particular solution are summarized briefly below, in no particular order:

Localization for multiple language support
Event sourcing using Entity Framework Core and SQL Server as persistent storage, including snapshots and retroactive events
EventStore repository and DataEntity generic repository. Persistence can be swapped between them, fine-grained to individual entities
Persistent application configurations with optional encryption
Data operation auditing built-in (for entities which are not using the EventStore)
Local user management with ASP.NET Core Identity
Clean separation of data entities and domain objects and mapping between them for persistence/retrieval using AutoMapper
ASP.NET Core MVC with Razor Components used for presentation
CQRS using handler abstractions to support MassTransit or MediatR with very little change
Service bus abstractions to support message-broker solutions like MassTransit or MediatR (default implementation uses MassTransit’s mediator)
Unforcefully promoting Domain-Driven Design with aggregates, entities and domain event abstractions.
Lightweight authorization framework using ASP.NET Core AuthorizationHandler
Docker containerization support for SQL Server and Web app

Some other goodies:

Password generator implementation based on ASP.NET Core Identity password configuration
Razor Class Library containing ready-made Blazor components for commonly used features such as CRUD buttons, toast functionality, modal components, Blazor Select2, DataTables integration and page loader
Common library with various type extensions, result wrapper objects, paged result data structures, date format converter and more.

Architecture Overview

Further below is a figure depicting the overall architecture in terms of layers and their components. The figure is meant to be a representation of how the actual solution is layered and show the gradual interrelationships between the layers, as opposed to simply showing the logical structure of a clean architecture.

In any case, the below diagram taken from Jason Taylor’s talk at NDC Sydney (2019), broadly depicts the logical structure of the architecture:

The actual solution consists of several projects, separated in folders representing the layers for convenience. The below figure is a code map generated from the solution. It shows the different layers and projects, along with their inter-dependencies.

As you can see from the arrows, all dependencies point downwards (or inwards if this was a circle diagram). there are no arrows pointing upwards between the Core, Infrastructure and Presentation layers.

The Core Layer

The Core Layer is made up of two parts, the inner core and outer core. The inner core is the domain and the outer core is the application. This consists of two projects in the solution under the Core folder, the Application and the Domain projects.

Inner Core (Domain Layer)

This layer contains application-independent business logic. This is the part of the business logic which would be the same even if we weren’t building a software. It is a formulation of the core business rules.

The organization of this project follows Domain-Driven design patterns, although this is a matter of preference and can be handled any way you see fit. This includes:

Aggregates, entities, value objects, custom domain exceptions, and interfaces for domain services.
Interfaces for domain-driven design concepts (i.e. IAggregateRoot, IDomainEvent, IEntity).
Base implementations of aggregate root and domain event. Also contains specific domain events pertaining to the business processes.

Outer Core (Application Layer)

This layer contains application-specific business logic. This contains the “what” the system should do. This includes:

Interfaces for infrastructure components such as repositories, unit-of-work and event sourcing.
Commands and Queries models and handlers
Interfaces and DTOs for cross-cutting concerns (i.e. service bus)
Authorization operations, requirements and handlers implementations
Interfaces and concrete implementations of application-specific business logic services.
Mapping profiles between domain entities and CQRS models

The Infrastructure Layer

This layer contains details, concrete implementations for repositories, unit-of-work, event store, service bus implementations etc. This contains the “how” the system should do what is supposed to do. The decoupling between the application layer and the infrastructure layer is what allows solution structures like this one to change and/or add specific implementations as the project requirements change.

In overview, this layer contains:

Generic and specific repositories implementations
EF DbContexts, data models and migrations
Event sourcing persistence and services implementations
Implementations for cross-cutting concerns (i.e, application configuration service, localization service etc.)
Data entity auditing implementation

This consists of 3 projects in the solution under the Infrastructure folder, the Auditing, Data and Shared projects.

The Auditing project consists of various extensions methods for DbContext, primarily related to SaveChanges. It is responsible for generating auditing records for each tracked entity’s changes.

The Data project contains domain and generic (CRUD and event-sourcing) repository implementations, DbContexts, EF Core migrations, entity type configurations (if any), event store implementation (including snapshots), data entity to domain object mappings, and persistence related services (i.e. a database initializer service).

The Resources project contains localized shared resources and resource keys, along with localization services implementations.

The Shared project contains service implementations for cross-cutting concerns such as user management and authentication, file storage, service bus, localization, application configuration and a password generator.

The Presentation Layer

This layer essentially contains the I/O components of the system, the GUI, REST APIs, mobile applications or console shells, and anything directly related to them. It is the starting point of our application.

For this starting point solution, it contains the following:

ASP.NET Core MVC web application using Razor Components
A shared class library containing common Razor Components, such as toast notifications, modal components, Blazor Select2, DataTablesJS integration and CRUD buttons.

The Common Layer

This single class library contains common types used across all other layers. What you would typically include in this library is things that you would wrap up into a Nuget package and use in multiple solutions. For clarification, this does not represent the Shared Kernel strategic pattern in DDD. Some of these include:

A generic Result wrapper
Paged result models for query operations
CLR type extensions
Notification models
Custom attributes and converters

Yes, yes, give me the code

The repository for the source code of this solution can be found here. The solution includes an extremely basic domain model for an online shop application, as an example. The UI part for this is not included however. The order domain exists to simply showcase the different elements of the architecture.

Final thoughts

Just like any software solution, this is not a one-size-fits-all architecture. It is simply what worked very well for me in my projects. As mentioned in the introduction of this post, there is still quite a lot to include in this solution, therefore I will be updating the repo on GitHub, as well as this post, whenever something new is added.

Please feel free to leave any feedback or suggestions on this, and if you would like to have anything in particular be included in the project.

Future work

In the near future, I’ve planned to make the following additions/changes to the solution:

Add support for caching, with an implementation for Redis
Replace MVC for presentation with Blazor Server
Include a RESTful API for domain business logic
Additional implementation of event-sourcing using EventStoreDB

Resources

Here are some additional posts you may find helpful in understanding what clean architecture is all about:

https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/

https://www.oncehub.com/blog/explaining-clean-architecture

DEV Community: thecodewrapper

The Evolution of the Developer in the Era of AI Agents

From Tool to Teammate

Phase 1: The Mild Shift — From Writing Code to Reviewing It

Phase 2: The Significant Shift — Developers as Architects

Why Developers Will Not Disappear

A New Skill Set Emerges

The Risk Is Not AI — It Is Stagnation

A More Human Role, Not a Less Human One

Final Thoughts

The 3 Most Practical Features of C# 14 for Everyday Developers

Null-Conditional Assignment

Caveats

The field Keyword

Caveats

Extension Members and the Extension Syntax

When to Use

Caveats

Conclusion

How to: Properly Simulate a Race Condition in C#

Understanding a Race Condition with a Simple Counter

Why is this a race condition?

A More Real-World Example: Bank Account Transactions

Thread Scheduling is Non-Deterministic

CPU Speed and Core Allocation

JIT Optimizations & Memory Reordering

What if we increase thread count to 1000?

Ensuring a Race Condition Always Occurs

Why does this happen?

A More Natural Way – Using a Semaphore to Force Contention

Conclusion

A consolidated guide to Well-Architected Frameworks

Reliability

Design for Failure

Implement Backup and Restore Procedures

Utilize Redundancy and Replication

Monitoring and Alerting

Implement Scalability and Elasticity

Ensure Disaster Recovery

Automated and Manual Recovery Procedures

Security and Compliance

Best Practices

Security

Implement Identity and Access Management (IAM)

Protect Data at Rest and in Transit

Detect and Respond to Threats

Implement Network Security Controls

Maintain Compliance and Governance

Best Practices

Cost optimization

Implement Cost Transparency and Monitoring

Manage Resource Utilization

Right-Size Resources

Use Appropriate Pricing Models

Automate Cost Management

Best Practices

Performance Efficiency

Optimize Resource Selection

Continuous Performance Monitoring

Implement Elasticity

Continuous Optimization

Encourage Experimentation and Innovation

Best Practices

Operational Excellence

Gain Operational Insights

Automate Operational Tasks

Manage Configurations

Efficient Change Management

Continuous Improvement

Best Practices

Sustainability

Improve Energy Efficiency

Optimize Resource Utilization

Leverage Sustainable Infrastructure

Utilize Renewable Energy

Design for Sustainability

Best Practices

Resources

Conclusion

Unlock Your Potential: Building Custom Tools as a Developer

The `field` Keyword