DEV Community: Łukasz Reszke

Which one to use? eql? vs equal? vs == ? Mutant Driven Development of Country Value Object

Łukasz Reszke — Mon, 20 Jun 2022 12:43:53 +0000

Recently after introducing a new value object to a project I ran mutant to verify my test coverage quite early. It turned out that I missed a few places when it comes to tests, but also technical design of production code. In this post, I'll show you my development process for the Country Value Object.

When you think about Value Object it's important to get the difference between eql?, equal? and == operators. Those differences were quite important in the class design process.

What is Value Object?

So long story short, a value object is an object whose equality is based on its value, not its identity.

Code sample

This is a simple country object. Its purpose is to protect the application from using countries that are not supported.

  class Country
    SUPPORTED_COUNTRIES = [PL = "PL", NO = "NO"].freeze

    protected attr_reader :iso_code

    def initialize(iso_code)
      raise unless SUPPORTED_COUNTRIES.include?(iso_code.to_s.upcase)
      @iso_code = iso_code
    end

    def to_s
      iso_code.to_s
    end

    def eql?(other)
      other.instance_of?(Country) && iso_code.eql?(other.iso_code)
    end

    alias == eql?

    def hash
      iso_code.hash
    end
  end

Besides that, as you can see in the tests below, no matter how we use the country object, we want it to always get the proper value of the country's iso code.

  class CountryTest < TestCase
    cover Country

    def test_returns_no
      assert_equal "NO", Country.new("NO").to_s
      assert_equal "NO", Country.new(:NO).to_s
      assert_equal "NO", Country.new(Country::NO).to_s
    end

    def test_returns_pl
      assert_equal "PL", Country.new("PL").to_s
      assert_equal "PL", Country.new(:PL).to_s
      assert_equal "PL", Country.new(Country::PL).to_s
    end

    def test_equality
      assert Country.new(Country::PL).eql? Country.new(Country::PL)
      assert Country.new(Country::NO).eql? Country.new(Country::NO)

      assert Country.new(Country::PL) == Country.new(Country::PL)
      assert Country.new(Country::NO) == Country.new(Country::NO)
    end

    def test_only_supported_countries_allowed
      assert_raises { Country.new("NL") }
      assert_raises { Country.new("ger") }
      assert_nothing_raised { Country.new("pl") }
    end
  end

This is our starting point. Looks ok, doesn't it? Before finishing the job of designing this class, let's run mutant tests and verify the results.

Let's kill some mutants

We'll focus on increasing the mutant coverage of equality-related methods.

Let's look at result of first bundle exec mutant run

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other.instance_of?(Country)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  iso_code.eql?(other.iso_code)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other.instance_of?(Country) || iso_code.eql?(other.iso_code)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other && iso_code.eql?(other.iso_code)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  true && iso_code.eql?(other.iso_code)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  Country && iso_code.eql?(other.iso_code)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  self.instance_of?(Country) && iso_code.eql?(other.iso_code)
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other.instance_of?(Country) && iso_code
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other.instance_of?(Country) && true
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other.instance_of?(Country) && other.iso_code
 end

 def eql?(other)
-  other.instance_of?(Country) && iso_code.eql?(other.iso_code)
+  other.instance_of?(Country) && iso_code.eql?(self.iso_code)
 end

 def hash
-  iso_code.hash
+  raise
 end

 def hash
-  iso_code.hash
+  super
 end

 def hash
-  iso_code.hash
 end

 def hash
-  iso_code.hash
+  nil
 end

 def hash
-  iso_code.hash
+  iso_code
 end

 def hash
-  iso_code.hash
+  self.hash
 end

The - sign symbolizes removed line of code. The + sign symbolizes line of code introduced by mutant. So even though there are tests that look quite good, the result is poor. This causes false sense of security.

This is the summarized score that we'll start with:

Integration:     minitest
Jobs:            1
Includes:        ["test"]
Requires:        ["./config/environment", "./test/support/mutant"]
Subjects:        4
Total-Tests:     523
Selected-Tests:  4
Tests/Subject:   1.00 avg
Mutations:       72
Results:         72
Kills:           55
Alive:           17
Timeouts:        0
Runtime:         26.23s
Killtime:        23.41s
Overhead:        12.09%
Mutations/s:     2.74
Coverage:        76.39%

Let's increase that coverage!

This is a good point in time to copy the code and try to increase it's mutant coverage 😉

Heal the code

At a first glance it looks like our test suite is not complete. Let's try to increase mutant coverage by adding missing tests.

    def test_values_equality
      refute Country.new(Country::PL).eql? Country.new(Country::NO)
      refute Country.new("PL").eql? "PL"
    end

So in this test we expect that

Country objects of two different countries are not equal
Value object is not the same thing as simple string

All right so this test removes most of the problems. Actually, there is 6 more issues left:

 def hash
-  iso_code.hash
+  raise
 end

 def hash
-  iso_code.hash
+  super
 end

 def hash
-  iso_code.hash
 end

 def hash
-  iso_code.hash
+  nil
 end

 def hash
-  iso_code.hash
+  iso_code
 end

 def hash
-  iso_code.hash
+  self.hash
 end

How can we kill those mutants?

Making hash method more robust

  def hash
    Country.hash ^ iso_code.hash
  end

And run mutant again

 def hash
-  Country.hash ^ iso_code.hash
+  raise
 end

 def hash
-  Country.hash ^ iso_code.hash
+  super
 end

 def hash
-  Country.hash ^ iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  nil
 end

 def hash
-  Country.hash ^ iso_code.hash
+  Country.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  nil ^ iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  Country ^ iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  self.hash ^ iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  Country.hash ^ nil
 end

 def hash
-  Country.hash ^ iso_code.hash
+  Country.hash ^ iso_code
 end

 def hash
-  Country.hash ^ iso_code.hash
+  Country.hash ^ self.hash
 end

Well... not good, not bad. Different mutants were injected in the code. Still, there are some survivors.

Step back. What are we trying to achieve?

We're trying to design Value Object.

Two Value Objects are equal when:

they have the same hash values, we have such a test
when their classes are the same

Once again it looks like we are missing some tests.

Let's write a test that will check if the hash value of two value objects are equal.

  def test_hash_equality
    assert Country.new(Country::PL).hash.eql? Country.new(Country::PL).hash
  end

And now let's run mutant and see the results.

 def hash
-  Country.hash ^ iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  nil
 end

 def hash
-  Country.hash ^ iso_code.hash
+  Country.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  nil ^ iso_code.hash
 end

 def hash
-  Country.hash ^ iso_code.hash
+  iso_code.hash
 end

So what is mutant trying to tell us?

If you're following along, modify the hash method to one of the suggestions and see what happens. Yep. The tests are still passing! And they shouldn't be, right?

I think we're missing a test to make sure the modification that we just did would be detected if the hash method was changed. Specifically I mean the step that we just did, so adding the class of the Value Object to the equation.

Let's fix this by extending the hash_equality test case by few negative scenarios testing the hash method.

  def test_hash_equality
    assert Country.new(Country::PL).hash.eql? Country.new(Country::PL).hash

    # new cases below
    assert_not_equal Country.new(:PL).hash, (Country.hash ^ "NO".hash)
    assert_not_equal Country.new(:PL).hash, (Country.hash ^ "PL".hash)
    assert_not_equal Country.new(:PL).hash, (Country.new(:NO).hash)
    refute Country.new(Country::PL).hash == "PL".hash
  end

Now after running the mutant we're good :)

Integration:     minitest
Jobs:            1
Includes:        ["test"]
Requires:        ["./config/environment", "./test/support/mutant"]
Subjects:        4
Total-Tests:     525
Selected-Tests:  6
Tests/Subject:   1.50 avg
Mutations:       78
Results:         78
Kills:           78
Alive:           0
Timeouts:        0
Runtime:         37.15s
Killtime:        33.76s
Overhead:        10.03%
Mutations/s:     2.10
Coverage:        100.00%

Why did we use `eql?` instead of `==`

The == operator compares two objects based on their value. For example

1 == 1 # true
1 == 1.0 # true
1.hash == 1.0.hash #false

For simple class:

    class Klass
      attr_accessor :code

      def initialize(code)
        @code = code
      end
    end

The test fails

    def test_klass
      assert Klass.new("a") == Klass.new("a")
    end

The eql? method compares two objects based on their hash.

2.eql? 2 # true
2.eql? 2.0 # false

Couldn't we just do it like this...?

    def test_klass
      assert Klass.new("a").eql? Klass.new("a")
    end

Nope.

Two objects with the same value. But! The hash is different. When the hash method is not overwritten, it's based on the object's identity. So it's something that we don't want when we think about Value Objects.

In general, it's better to use .eql? method for the Value Object if you want to make sure that there's no hash colision.

What about equal?

Why isn't the equal? method also aliased to the eql? operator? The reason is the fact that the equal? method checks the identity of the object.
Let's look at an example.

    def test_equality
      first = "a"
      second = "a"

      assert first.equal? second 
    end

The test fails. Check the identity of those two objects, they're different.
first.__id__ != second.__id__

Besides that, overwriting equal? is not recommended.

Final Value Object

class Country
  SUPPORTED_COUNTRIES = [PL = "PL", NO = "NO"].freeze

  protected attr_reader :iso_code

  def initialize(iso_code)
    raise unless SUPPORTED_COUNTRIES.include?(iso_code.to_s.upcase)
    @iso_code = iso_code
  end

  def to_s
    iso_code.to_s
  end

  def eql?(other)
    other.instance_of?(Country) && iso_code.eql?(other.iso_code)
  end

  alias == eql?

  def hash
    Country.hash ^ iso_code.hash
  end
end

SOLVING THE AZURE DEVOPS RELEASE ERROR CODE: ERROR_FILE_IN_USE

Łukasz Reszke — Tue, 14 Sep 2021 20:15:57 +0000

In this short post let’s take care of an annoying error in Azure DevOps Release – Azure App Service Deploy task.

Error: Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'webapi20210902.txt' on the destination because it is locked by an external process.  In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt.  Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
Error: The process cannot access 'C:\home\site\wwwroot\logs\webapi20210902.txt' because it is being used by another process.
   at Microsoft.Web.Deployment.NativeMethods.RaiseIOExceptionFromErrorCode(Win32ErrorCode errorCode, String maybeFullPath)
   at Microsoft.Web.Deployment.FileEx.Delete(String path)
   at Microsoft.Web.Deployment.FilePathProviderBase.Delete(Boolean whatIf)
Error count: 1.

The problem is that the new version of the application cannot be released, because the log file is locked. What was also interesting is the fact that every time retrying the task did help.

The Azure App Service Deploy task has an additional setting called Take App Offline. You can locate this setting in the Additional Deployment Options section. But it didn’t help in my case. Actually, modifying any settings in the task didn’t help. The problem was lying in the application itself. More specifically, in logger.

Solution

I am presenting the solution that worked for me, and I also hope it can help you (let me know in the comment if you had this specific problem).

The problem is really simple. Serilog (the logger of choice for my project) didn’t release the handle to the log file automatically when the application was shut down. Adding Log.CloseAndFlush into the Main method’s finally block solves that issue.

public static void Main(string[] args)
        {
            try
            {
                var configuration = new ConfigurationBuilder()
                    .SetBasePath(Directory.GetCurrentDirectory())
                    .AddJsonFile("appsettings.json")
                    .Build();

                var instrumentationKey = configuration.GetValue<string>("ApplicationInsights:InstrumentationKey");

                Log.Logger = new LoggerConfiguration()
                    .MinimumLevel.Debug()
                    .MinimumLevel.Override("Microsoft", LogEventLevel.Information)
                    .Enrich.FromLogContext()
                    .WriteTo.File("logs\\webapi.txt", rollingInterval: RollingInterval.Day)
                    .WriteTo.Console(theme: AnsiConsoleTheme.Code)
                    .WriteTo.ApplicationInsights(
                        new TelemetryConfiguration
                            {InstrumentationKey = !string.IsNullOrEmpty(instrumentationKey) ? instrumentationKey : ""},
                        TelemetryConverter.Traces)
                    .CreateLogger();

                CreateHostBuilder(args).Build().Run();
            }
            finally
            {
                Log.CloseAndFlush();
            }

Previously I didn’t use try / finally block here. Adding the block fixed the issue with the locked file (ERROR_FILES_IN_USE).

Disabling unready code with Azure Feature Management

Łukasz Reszke — Mon, 13 Sep 2021 19:08:22 +0000

Working without branches and PRs

When my team and I started developing new product, I was looking for a way to deliver high quality code effectively. Previously most of us worked with branch-based workflows with Pull Requests. From my experience it's quite standard way. I haven't seen many projects or meet many people working differently. However, I did work once in an green field'ish project with PRs. It was quite annoying. Especially, when for the POC phase I was alone. I was taught to do it like that and I didn't think about more effective ways.

Looking for inspiration

But in the meantime when we were starting that project I joined polish dev Instagram community and had a chance to talk with @andrzejkrzywda . Andrzej is CEO of Arkency, consulting agency that works with Ruby and Rails. The thing that makes Arkency special (and that was mind-blowing for me) is the fact that they have their own, very specific workflow. And yet, very different than what is accepted. Andrzej did some marketing on the Instagram stories. And it couldn't end up different. I bought the Async Remote book, where I learned of how developers in Arkency work... without branches (there are also few other interesting things in their workflow, check the book out).

Chance to test things out

I thought to myself that a Greenfield-ish project, that we need to develop sooner than later, is a good opportunity to at least try no-branches approach from the beginning. At the end of the day it should be quicker. Especially when there's not so many developers in the beginning (our team started with 2 backend and 1 frontend developers only). And there's not so many things that you can break :)

So we have started working that way. But at a certain point you stop developing the product just for sake of developing it. You're getting your first customers and sometimes its getting hard to deliver full feature in few commits. And we felt that we didn't want to go back to the old flow. This felt so much more productive.

Then I reminded myself that there was the answer in the Async Remote book. But before we get there, and see how we can use the azure feature management from the title to keep that flow, let's establish few things.

Let's establish few things

Before you stop reading and think we're crazy because we work without reading each others code or what not, I want you to know one thing. No branches and no Pull Requests is not equal to No Code Reviews. No. We do review each others code. And also, when someone is in doubt, there's a possibility to do the PR. The thing is, it's not mandatory. You can do that when you feel that you need colleagues input before you commit to the master branch. No hard rules. Just guidelines that you follow.

Find the right tool that suits your needs

I am not against branches. Do whatever works for you and your team. I've worked like that for quite some time. But the other way feels way more productive. No offence :)

All right, so we have that established. Let's see how Azure Feature Management can help us :)

The problem

The problem that we're trying to solve with Azure Feature Management is the fact that it sometimes might be hard to commit entire feature within one commit into the master branch, and then deploy it to production. It could mess few things up.

In our case it was the frontend view that has to be invisible conditionally. But it could be different. For example, you might want to change parts of backend code - introduce easily switchable branching with feature toggling. Azure Feature Management would also help you there.

The idea of solving the problem using Feature Management

So to solve this problem we can use Feature management (aka Feature Toggling) in Azure. Azure Feature Management allows you to disable parts of the code that aren't ready. Or hide those parts, if we're thinking about an UI feature.

What I really like about Feature Management in Azure is the fact that you can set it up in a way that the feature can be available only at certain time window or only for certain percentage of users.

Setting up Feature Management in Azure

Setting up the Feature Management in Azure is quite simple. Find the App Configuration resource and follow the steps in the wizard. If you get into trouble, visit this link for more detailed guidance.

Then in the operations section there's Feature Manager option

Now you can create feature flags :)

Feature flags have option to use feature filters. However this is out of scope of this post.

C# implementation

So now as we have feature management set in the Azure, we can implement it in C#. To solve our problem, we'll create an endpoint that returns list of currently enabled features. Then, the frontend client will be able to manipulate the view and navigation based on the result.

Necessary packages

Let's start with packages. The packages that you should install are

Microsoft.FeatureManagement.AspNetCore, Microsoft.Azure.AppConfiguration.AspNetCore

Program.cs configuration

To enable Azure Feature Management extend your Host builder by highlighted lines (the ConfigureAppConfiguration extension)

    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
            webBuilder.ConfigureAppConfiguration((hostContext, config) =>
            {
                var settings = config.Build();
                var connection = settings.GetConnectionString("AppConfig");
                config.AddAzureAppConfiguration(options =>
                {
                    options.Connect(connection).UseFeatureFlags();
                });
            }).UseStartup<Startup>())

Startup.cs

Simply Add Feature Management :)

services.AddFeatureManagement();

The Endpoint for Frontend

The endpoint is simple and uses configured Azure Feature Management SDK to manage App Configuration connection. The frontend client gets all the available features with a field describing whether it's enabled or not.

    [Route("api/[controller]")]
    public class FeatureManagementController : Controller
    {
        private readonly IFeatureManager _featureManager;

        public FeatureManagementController(IFeatureManager featureManager)
        {
            _featureManager = featureManager;
        }

        /// <summary>
        /// Returns feature flags that are set up for the application
        /// </summary>
        /// <returns>List of feature flags. Feature flag contains name and status (enabled or not)</returns>
        [HttpGet]
        public async Task<IActionResult> GetFeatureFlags()
        {
            var featureFlags = new List<Feature>();
            await foreach (var featureFlag in _featureManager.GetFeatureNamesAsync()) // Fetches all Feature names from Azure 
            {
                 // IsEnabledAsync method call returns the value from App Configuration, Feature Management tab for desired feature flag.
                featureFlags.Add(new Feature(featureFlag, await _featureManager.IsEnabledAsync(featureFlag)));
            }

            return Ok(featureFlags);
        }
    }

The using that allows you to use IFeatureManager interface:

using Microsoft.FeatureManagement;

Summary

Azure Feature Management lets you enable and disable certain parts of code
There's dedicated SDK that makes it easier to fetch available feature flags and their status
Azure Feature Management is available through App Configuration service on Azure
Because of feature flags, it's possible to commit and push that is not yet ready to be used by an end user
It's also possible to manipulate who gets the certain feature enabled by using feature filters, which is out of this blog post scope

Have you ever tried Azure Feature Management? What's your opinion on that?

Subdomains and Bounded Contexts

Łukasz Reszke — Sat, 14 Aug 2021 12:13:22 +0000

This post is a summary, a note to myself about the differences of Subdomains and Bounded contexts. Those terms are often used by Domain-Driven Design practitioners. There was a time when I used to mix them up a little bit. Hope you can find this useful. If you find any inaccuracy, let me know. I am still improving my DDD practice and knowledge.

Subdomains

Let's start with what a subdomain is. Subdomains lay in the problem space. One large problem domain can be split into multiple subdomains. The reason for partitioning a larger domain into smaller subdomains is that it makes it easier to manage complexity, and separate the important parts of the system from the rest of it.

Wait, aren't all parts of the system equally important?

Well, in DDD the subdomains are split into 3 categories:

Core Domain
Supportive Subdomain
Generic Subdomain

The Core Domain

The Core Domain is the most important part of the business domain. It's what makes the application worth building in the first place. It's the reason for the application being created from scratch instead of being bought.
What does it mean for us, developers? This is something that makes our business special and unique (in most cases). It's also something that may affect the decision whether the software is developed outside or in-house. Besides that, we should put most of the effort here and craft this part of the system very carefully. Wait, aren't all parts of the system equally important?

The thing worth remembering is the fact that business might change over time, and so might Core Domain. Keep your head open and listen to what people say. After some time spent with the initial Core domain, you might find a new one, that evolved from a supportive subdomain, for example.

The Supportive Subdomain

The supportive word of the supportive subdomain term means that this part is supporting the Core domain. In other words, the supportive subdomains deliver functions that support proper functioning of the Core domain. Those subdomains are specific for the organisation and it's processes, that's why we cannot buy them. However, the supportive subdomains are a little bit less important than the core domain. This less importance allows us, developers, to put less effort here on the quality.

And don't get me wrong, you shouldn't use all the anti-patterns that you know in the supportive subdomain. The thing is that there are more and less important parts of the problem that the software system will be solving. Hence, it's acceptable to do some compromise here if necessary. For example because of the time pressure or other drivers that exist in your environment.

The Generic Subdomain

The Generic Subdomains are important parts of the business processes, however, those are not unique. Because of that, the generic subdomains can be bought. A good example is invoicing, payments, email sending service. If your business isn't dealing with those things (because then it would be core domain), there's a high chance that it would be more pragmatic to buy an out of the box solution and integrate with it. Also, developing a generic subdomain in house is probably not going to bring your business the competitive advantage that the Core domain does. However, if you decide to develop a generic domain in-house, it might over time turn into the core domain. At least according to the theory :D. Or an idea that's sounds great in the beginning might turn into nightmare as well. Think about custom made ORMs...

Bounded Context

Bounded Contexts lay in solution space. They help with maintaining the integrity of domain models within certain context, by clearly defining boundaries of model's responsibility in the code. The reason for that is the fact that certain things might have different meanings. For example, customer might be described by it's name, age, username, etc. in one context. In payments context, the same customer might be described just by an identifier and credit card number.
Bounded context has linguistic barriers (yes, language is important, even for us, geeks😄). The language comes from the domain experts and should be reflected in our code representing the domain model. Definitions of terms are clear within given bounded context. Such as mentioned customer might mean two different things in two different contexts. And the thing is... that you have to catch those differences.
How to do that?
What works for me is listening to domain experts and learning their language. I also keep in mind which part of the process they're dealing with or talking about. Or actually I am trying to catch that. Besides that I ask questions if I don't understand something or I am uncertain what they have in their minds during discussions. You need to find your way.

Bounded Context Boundaries

As I mentioned, I try to keep clear boundaries between my bounded contexts. What is also important is the fact that each BC has it's own domain model, that doesn't share any data with other BCs. For example, only one BC would be responsible for customer's credit card number maintanence.
In other words, BCs should be autonomic. The autonomy means that it's possible to make decisions.

BCs are important

Why do I think BCs are important? In few project that I saw there was a problem with the models. Besides being anemic, those models held too much data. The data usually was related to the same word, but in different context of using this word. This leads to the classes that are really hard to change, because changing one thing is often breaking something else. That's because the data is coupled on different levels. Also BCs are closely related to problem subdomains. In my experience, keeping one BC per one problem domain often works very well. The reasoning is that the class has only one reason to change then. That's actually what I consider following SRP. Also, I try to craft the model to do one thing and do it well (and preferably fast 😄).

What about One model to rule em' all

One model to rule them all doesn't look like a good approach. I experienced that it's better to make 3 or 4 customer classes if needed. Each of it in it's own context. And make it do exactly that small thing that it has to do. Nothing more, nothing less. Maintaining complex system is easier when its split to multiple code models with clear boundaries. With one big(ger) model it is easier to group wrong concepts together.

Other benefits

I found it easier to split work between people. It's much easier to work within BC. Less likely that we'll have to modify the same thing at the same time.

Summary

Subdomains lay in the problem space
There are 3 categories of subdomains:
- Core
- Supportive
- Generic
The Core subdomain is the place where most of the modeling time should be invested
Bounded contexts are the answers, the solution for the problem space
One entity, such as a Customer, might be represented in multiple Bounded Contexts
The solution benefits from autonomic BCs
One model to rule them all might not be the best choice for complex applications (but it might be good for CRUD)

Sharing data between modules in modular monolith

Łukasz Reszke — Wed, 05 May 2021 20:41:28 +0000

Recently my team and I are working on a modular monolith. We’ve been inspired by Kamil Grzybek’s solution available right here. This repository is awesome, and if you haven’t seen it, I strongly recommend taking a look.

Generally, during development, keeping our boundaries when going through the Command/Write part of our CQRS architecture was quite easy. However, once we started thinking about the Query/Read part, we noticed that we could use some data from module A in module B. Then we thought about different approaches how we could get the data efficiently, but also without crossing logical boundaries, which is quite easy, because of no physical separation.

Querying other modules’ data… meh

As the data is stored in one database, it’s tempting to just query data from another schema. However, it creates coupling on the database level. We have set a rule, that you shouldn’t build a query that touches more than one schema. So we decide to not go with this approach. So even though we have only logical separation right now, if we’d decide to physically separate the database as well, it wouldn’t be possible with such coupling. Simple, but it wasn’t acceptable in our case.

Separate Backend For Frontend

Another option was preparing Backend for Frontend approach. The BFF would be responsible for gathering data from different modules and then returning such data to the frontend. The data could be gathered from REST APIs in the backend that hosts the frontend and then converted into a format that is easily useable in the Frontend.

This approach is very reasonable, but I don’t like the fact that within one system I’d have to introduce such overhead. Also, if the modular monolith will need to separate a Microservice outside of it, and the Microservice goes down, it’d be impossible to let the user work with the UI. Even if this is just a different part of the system, that doesn’t need anything else besides one piece of information. But if the part of the system goes down… you ain’t gonna get part of the data.

On the other hand, if the entire modular monolith goes down… well, the same story, isn’t it? But still, as we’re owning the frontend we should actually make it easy to work with, right? After all, I feel like I can do more (and quicker) in the backend. So this is definitely the way to go, but perhaps there’s something better.

Frontend calls REST APIs and connects the data

This approach would be similar to the previous one. Frontend would call multiple REST API endpoints and put it all together into a view. I don’t like this approach because it feels like doing too much on the frontend side. Again, I prefer to prepare the data on the backend and return a view model that can be easily rendered. But that’s my personal preference, based on the fact that I prefer working on the backend. This approach is definitely good for developers that feel more confident working in JavaScript. Personally, I don’t like to push too much pressure there. So I didn’t decide to go with this approach.

Duplicating necessary data to build Views/Read models

As I said, I prefer to work on the backend side and use the frontend just for rendering the data. Additionally, we are currently using CQRS. So our decision was to build eventually consistent Read Models.

But… how to get data?

Okay, it felt weird for me at first glance. But… we just duplicate that between modules. So if module A is the technical authority of some data, and module B needs it, we just get it there through integration events. So if module B is interested in some data from module A, it just subscribes to it’s events. This way, there’s no coupling between those modules. The duplicated, cached data is only used for Read capabilities. This data is never modified outside of module A, because module A is a single source of truth.

Because of that, we’re able to cache the data in the module’s B database and build Views (the database Views) to be able to provide the data that the frontend needs quickly, through raw SQL queries called from Read side of the application.

Also, this way, if this is ever a separate service or for some reason, part of the app is down, we are still able to get the data from the calling module.

Generally, when I think about it, this approach could be also applied to Microservices/SOA as well. It’s not solely for the modular monolith itself.

What do you think about the approach with duplicating the data vs BFF? Which one would you go with?

Let's stop talking SQL

Łukasz Reszke — Thu, 22 Apr 2021 18:02:12 +0000

Communication is often underestimated in our job. That's because when we start our journey with software engineering, we focus on the hard skills, such as backend language, frontend language, CI/CD, databases, infrastructure, and all the other sexy stuff. But as our seniority level increases and we get more and more experienced, we should start thinking about our soft skills as well. Because our job stops being just writing the code. Communicating with other team members and business gets more and more important.

In this post, I will use business interchangeably with the Product Owner, Manager, or anyone that should bring application requirements, in your company.

Unhealthy relation

Have you ever experienced when a business or Product Owner / Manager came to you and said that he wants you to display certain columns from the database on UI? Or that you should simply select, insert, whatever value into the database?

This is just an example. I hope you see where I am going. The business often gives us workarounds or what they think is the best technical solution, instead of requirements.

I truly believe that we need to understand the problem first before we solve it.

And let's be clear here. I don't mean that you need to learn about CROSS-JOINS to solve the problem. I mean to understand the purpose. The WHAT of what the person that talks with you want to achieve.

It might involve some discussions. It might require some time. Especially when you'll start digging for the first few times.

Looking through the prism of what we currently know

What I noticed is that the business or users of our application often look through the prism of the current system. Many times, it's not what the business or users really want. Talking with users or the business will lead to a better solution.

Ask few questions. Try to truly understand a problem. You might get surprised when during discussions you'll run into a solution that doesn't require writing a single line of code.

Let's stop talking SQL.

Simple implementation of pessimistic concurrency in Entity Framework

Łukasz Reszke — Wed, 21 Apr 2021 19:21:23 +0000

An aggregate root can protect invariants by mediating access to internal components. However, it cannot prevent aggregate from reaching an inconsistent state, due to multiple users modifying it. We need to provide a mechanism, which will ensure that other's user's modification does not negatively affect the state of the transaction for other concurrent users.

The good thing is that in Entity Framework we can easily implement the pessimistic concurrency, based on the aggregate's version.

Solution

builder.Property(x => x.Version)
  .HasColumnName("Version")
  .IsConcurrencyToken()
  .HasDefaultValue(0);

The version has to be added to the aggregate. I added it into the base abstract class. Then, before every call of the SaveChanges method, increase the version. The Entity Framework will take care of the correct version being in the database.

If someone modifies the value of the aggregate and hence will increase the version, Entity Framework will throw an exception.

Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: Database operation expected to affect 1 row(s) but actually affected 0 row(s). Data may have been modified or deleted since entities were loaded.

How do you take care of your aggregate's consistency?

Secure data in a single Multi-Tenant Database in 3 simple steps

Łukasz Reszke — Tue, 20 Apr 2021 18:18:13 +0000

Often our applications have to support multiple customers, which are often called tenants. One of the popular options is a single multi-tenant database. This model requires each database table to contain an additional column, which is responsible for distinguishing to which tenant a data row belongs. In this post, I’ll show you how you can ensure that each tenant’s data is not available for other tenants.

Row Level Security

The solution that I often use is the MSSQL database’s mechanism called Row-Level security. The idea is quite simple. The database will only return results that fulfill the predicate. In my case, the predicate is simply the TenantId set for the current context. So the result contains only rows that have TenantId equal to the one set in session context. The session context can be set when you use both Entity Framework or Dapper. Let’s take a look at the code!

Security schema

First, let’s create a separate security schema. It’s recommended by Microsoft to keep security predicates and related functions in a separate schema.

CREATE SCHEMA [Security]

Security predicate

The next step is to create Security Predicate Function

CREATE FUNCTION [Security].[SecurityPredicate](@TenantId UNIQUEIDENTIFIER)
    RETURNS TABLE
    WITH SCHEMABINDING
AS
    RETURN
        SELECT 1 AS Result
    WHERE CAST(SESSION_CONTEXT(N'TenantId') AS UNIQUEIDENTIFIER) = @TenantId

As you can see, this function takes tenantId, which is always a GUID in my case, and checks, whether it’s equal to TenantId for the current session.

Add a policy

The last step for setting up the database is to add policy for specific table.

CREATE SECURITY POLICY [Security].[BlogPostsPolicy]
    ADD FILTER PREDICATE [Security].[SecurityPredicate]([TenantId]) 
        ON [dbo].[BlogPosts],
    ADD BLOCK PREDICATE [Security].[SecurityPredicate]([TenantId]) 
        ON [dbo].[BlogPosts] AFTER INSERT,
    ADD BLOCK PREDICATE [Security].[SecurityPredicate]([TenantId]) 
        ON [dbo].[BlogPosts] AFTER UPDATE,
    ADD BLOCK PREDICATE [Security].[SecurityPredicate]([TenantId]) 
        ON [dbo].[BlogPosts] BEFORE DELETE,
    ADD BLOCK PREDICATE [Security].[SecurityPredicate]([TenantId]) 
        ON [dbo].[BlogPosts] BEFORE UPDATE
WITH (STATE = ON, SCHEMABINDING = ON)

As you can see, I am using different predicates here:

Filter predicates filters out rows that do not belong to tenant specified in session context for read operations
Block predicates explicitly block write operations that violate the predicate

Working with the data

In order to work with data you have to execute following query, which will set session context of the tenant that you want to work with:

SP_SET_SESSION_CONTEXT N'TenantId', '{YOUR-TENANT-ID}'

Note, that if you do this in SQL Server Management Studio, it only works for the current tab. To use it with Entity Framework or Dapper, you just have to execute the same query (with session context) before executing the right query.

For Entity Framework, you can use following code to set it up

var connection = Database.GetDbConnection();

connection.StateChange += (_, @event) =>
{
    if (@event.CurrentState == ConnectionState.Open)
        connection.Execute("EXEC SP_SET_SESSION_CONTEXT @key=N'TenantId',        
            @value=@tenantId", new
            {
                tenantId = _tenantId
            });
};

If you work with Dapper, you can execute this code before each query

_connection.Execute("EXEC SP_SET_SESSION_CONTEXT @key=N'TenantId',     
    @value=@tenantId", new {tenantId});

And it’ll do the job 🙂

Summary

That’s it. Quite a simple approach for a single multi-tenant database that protects you from displaying data to the invalid tenant using a database mechanism. I really like this approach, because it protects you at the lowest possible level. Unless you do a mistake and for some reason set the tenant context to another tenant context, you should be quite safe and decrease the likelihood of a mistake.

Of course, there are few other options available when it comes to the multi-tenancy model. You can check them out here. If you’d like to read more about Row-Level Security, Microsoft has quite a good doc on that here.

3 things I like to keep in mind when unit testing

Łukasz Reszke — Mon, 19 Apr 2021 18:58:18 +0000

What’s the difference between good and bad unit tests? 🧐

Bad unit tests feel right in the beginning. They make you feel confident, because hey, you write tests.

But nothing really changes… Once you get into the refactoring part, and you have to refactor tests as well. And their assertions for the result. This leads to even longer development, even though you invested time in tests at the begging of the project. So this leads us to the conclusion that… not are tests are equally valuable. Some of them raise false alarms. Some unit tests don’t help you catch regression errors. Bad unit tests may be as well slow and are difficult to maintain.

Don’t write unit tests just for sake of writing unit tests! There are 3 things I always keep in mind when I am designing my unit tests.

Focus on the behavior, not on the implementation

When writing unit tests, especially testing the domain model, I avoid mocking anything. The reason is the fact that I want to focus on the behavior, on the outcome of the method. My goal is not to check how this is achieved. Because of this, I am able to change the implementation at any time, without worrying about rewriting the entire test.

Test your tests

This year, I first heard about mutation testing. It was a wow moment for me. Now, whenever I write unit tests, I check myself with the mutant. I check whether I have covered all the cases (and hence, killed all the mutants 👽). Using that tool is like using Grammarly, for example. First, you get a lot of corrections. But as you go, the number decreases, because you learn by doing. The same story goes with the mutant. Check your tests once you’re done to make sure you covered all the cases. You can read more about mutation testing here.

Don’t generalize early on

I found out that generalizing things too early (over-following the DRY principle) may actually slow you down in the long run. By generalizing I mean making (soon to be over-parametrized) seeding methods for the arrange part. Or too many hierarchical classes, just to avoid writing something twice. I always start simple, allow some duplication, and see where this takes me. I find myself refactoring the code often, especially when I work with a new domain. I found out that introducing generalization too early in tests makes it harder. Later, when it feels a little bit too messy, I really like introducing a builder pattern for seeding the data.

What are the rules that you follow when testing?

Originally published at lukaszcoding.com

Start using fields in C#. Using properties is not a good habit and won't do you any good...

Łukasz Reszke — Wed, 03 Mar 2021 17:24:32 +0000

A field is a variable of any time declared in the class. The fields are usually private, which means that they cannot be accessed from outside the class.

Field could be exposed by a public property - however, it's not recommended in every case.

Exposing a field by setter and getter might lead to an unwanted state of the system - that's because it's harder to keep control over what is assigned to a field.

Let's take the Address class as an example. If we expose just properties - we can write whatever we want into the zip code.

public class Address
{
    // Other properties
    public string ZipCode { get; set; }
}

static void Main(string args[])
{
    var address = new Address();

    address.ZipCode = "I can type whatever I want here!";
}

Let's refactor it and see if we can do it better.

public class Address
{
    // Other parts of Address class

    private string _zipCode;

  public void SetZipCode(string zipCode)
  {
    if(!string.IsNullOrEmpty(zipCode) && zipCode.IsValidZipCodeFormat())
            _zipCode = zipCode;
        else throw new ArgumentException(nameof(zipCode));
  }
}

static void Main(string args[])
{
    var address = new Address();

    address.SetZipCode("81-840");

    address.SetZipCode("abcdefgh"); // throws Argument Exception

    // Not possible anymore
  // address.ZipCode = "I can type whatever I want here!";
}

We encapsulated the knowledge of how to set the zip code and what rules have to be fulfilled within the SetZipCode method. Now, anyone calling this method will have to fulfill those rules.

Summary

Don't get me wrong, properties are awesome and they have their place. But I often see them misused and they're often a reason for lacking encapsulation. If possible - limit the possibility to modify your data with carefully crafted methods.

Join dotnetcoreschool.com and learn C#

The Difference Between Single And First Methods In C# -Explained

Łukasz Reszke — Tue, 02 Mar 2021 18:11:57 +0000

Have you ever wondered what's the difference between .Single and .First methods in C#? At the first glance, they both do the same. They return one element from the list... However, there are differences in the behavior of each.

Single

The Single method returns one element from a collection, based on a predicate. It looks through the entire list and looks for the desired element.

var users = new List<User>
{
    new() {FirstName = "George", LastName = "Doe", Age = 18},
    new() {FirstName = "Jane", LastName = "Doe", Age = 21},
    new() {FirstName = "Jay", LastName = "Doe", Age = 23},
    new() {FirstName = "John", LastName = "Doe", Age = 36},
    new() {FirstName = "Michael", LastName = "Doe", Age = 45},
};

var result = users.Single(x => x.FirstName == "George");

However, there's are two four things to remember:

.Single goes through the entire list, even if the first element matches the predicate right away. There's a reason for that, which is the fact that...
.Single throws an exception when there is more than one element matching the predicate. So, if there would be two users with the same first name in the list, the .Single method would throw an InvalidOperationException.
.Single throws the same exception when there's no element matching the predicate.
.Single also throws the InvalidOperationException when the source collection is empty.

What if the same example Single would be called without any predicate? You guessed it right - the InvalidOperationException would be thrown. That's because there is more than 1 element matching the predicate.

First

The First method without any parameter returns the first element from the collection.

var users = new List<User>
{
    new() {FirstName = "George", LastName = "Doe", Age = 18},
    new() {FirstName = "Jane", LastName = "Doe", Age = 21},
    new() {FirstName = "Jay", LastName = "Doe", Age = 23},
    new() {FirstName = "John", LastName = "Doe", Age = 36},
    new() {FirstName = "Michael", LastName = "Doe", Age = 45},
};

var result = users.First(x => x.FirstName == "George");

That's the first difference compared to the Single method (it would throw an exception if there was more than 1 element).

The First method similarly to the Single method can return an element from the collection based on a predicate. The difference is the fact that it returns the first element from the collection matching the predicate. It doesn't iterate through the entire collection to check for duplicates.
Similar to the Single method, the First method throws an InvalidOperationException when there's no element satisfying the condition in the predicate or when the sequence is empty.

The key difference to remember - the .First method doesn't throw an exception when there's more than one element matching the condition in the predicate. Also, the .First method without the predicate will return first element from the sequence (even though there might be more than 1 element).

What if I told you there are few more options?

Find

You might want to just element from the collection and don't worry about exceptions if it doesn't exist - the .Find method would be the right choice!

var users = new List<User>
{
    new() {FirstName = "George", LastName = "Doe", Age = 18},
    new() {FirstName = "Jane", LastName = "Doe", Age = 21},
    new() {FirstName = "Jay", LastName = "Doe", Age = 23},
    new() {FirstName = "John", LastName = "Doe", Age = 36},
    new() {FirstName = "Michael", LastName = "Doe", Age = 45},
};

var result = users.Find(x => x.FirstName == "xxx"); // returns null

Single or... default

You might want to search for an element and make sure that it's only one within the collection and not worry about an exception when it's not found - the .SingleOrDefault method would be the right choice! (note: it returns null when it doesn't find the element specified by criteria)

var users = new List<User>
{
    new() {FirstName = "George", LastName = "Doe", Age = 18},
    new() {FirstName = "Jane", LastName = "Doe", Age = 21},
    new() {FirstName = "Jay", LastName = "Doe", Age = 23},
    new() {FirstName = "John", LastName = "Doe", Age = 36},
    new() {FirstName = "Michael", LastName = "Doe", Age = 45},
};

var result = users.SingleOrDefault(x => x.FirstName == "xxx"); // returns null

var someoneWithDoeLastName = users.SingleOrDefault(x => x.LastName == "Doe"); // throws an exception

First or... default

You might want to get the first element matching the criteria and not worry about an exception when it's not found - the .FirstOrDefault method would be the right choice (note: it return null when it doesn't find the element specified by criteria)

var users = new List<User>
{
    new() {FirstName = "George", LastName = "Doe", Age = 18},
    new() {FirstName = "Jane", LastName = "Doe", Age = 21},
    new() {FirstName = "Jay", LastName = "Doe", Age = 23},
    new() {FirstName = "John", LastName = "Doe", Age = 36},
    new() {FirstName = "Michael", LastName = "Doe", Age = 45},
};

var result = users.FirstOrDefault(x => x.FirstName == "xxx"); // returns null

var someoneWithDoeLastName = users.FirstOrDefault(x => x.LastName == "Doe"); // returns first item from the list, in this example it would be George Doe, Age 18

Which one do you use the most?

PS. Get a Free Ebook with more LINQ examples at https://dotnetcoreschool.com

C# Loops Explained

Łukasz Reszke — Mon, 01 Mar 2021 19:53:29 +0000

Loop

A loop is a programming structure that repeats a sequence of instructions until a specific condition is met. Loops are used very often, that's why you must be comfortable with them.

An example of a loop is a while loop, which states that "while a condition is valid, keep looping". There are other loops in C# as well, as do while, for, and foreach.

Syntax

while (condition) 
{
    // Do something
}

While Loop Example

int i = 0;
int goal = 7;

while (i < goal)
{
    Console.Writeline("We didn't get there yet!");
    i++;
}

This block of code would write "We didn't get there yet!" exactly 7 times.

Foor Loop Example

          for (var i = 0; i < 7; i++)
            {
                Console.WriteLine($"Current Index is {i}");
            }

            /*
             * Output
             * Current Index is 0
             * Current Index is 1
             * Current Index is 2
             * Current Index is 3
             * Current Index is 4
             * Current Index is 5
             * Current Index is 6
             */

Foreach loop

            var names = new List<string> {"Lukasz", "Jan", "John", "Jane", "Monica"};

            foreach (var name in names)
            {
                Console.WriteLine($"How you doin', {name}");
            }

            /*
             * Output
             * How you doin' Lukasz
             * How you doin' Jan
             * How you doin' John
             * How you doin' Jane
             * How you doin' Monica
             */

And the last one is the do while loop

            var knowledgeLevel = 0;
            var knowledgeRequired = 1000;

            do
            {
                Console.WriteLine("Keep studying!");
                knowledgeLevel++;
            } while (knowledgeLevel < knowledgeRequired);

However...

There's one more looping mechanism that you can use. List class has it's own "ForEach" method.

            var names = new List<string> {"Lukasz", "Jan", "John", "Jane", "Monica"};

            names.ForEach(name => Console.WriteLine($"How you doin', {name}"));

            /*
             * Output
             * How you doin' Lukasz
             * How you doin' Jan
             * How you doin' John
             * How you doin' Jane
             * How you doin' Monica
             */

Are you learning C#?

If you're a person that wants to start learning C# and you want to get prepared for your first job - consider joining the .NET School

DEV Community: Łukasz Reszke

Which one to use? eql? vs equal? vs == ? Mutant Driven Development of Country Value Object

What is Value Object?

Code sample

Let's kill some mutants

Heal the code

Making hash method more robust

Why did we use eql? instead of ==

What about equal?

Final Value Object

SOLVING THE AZURE DEVOPS RELEASE ERROR CODE: ERROR_FILE_IN_USE

Solution

Disabling unready code with Azure Feature Management

Working without branches and PRs

Looking for inspiration

Chance to test things out

Let's establish few things

Find the right tool that suits your needs

The problem

The idea of solving the problem using Feature Management

Setting up Feature Management in Azure

C# implementation

Necessary packages

Program.cs configuration

Startup.cs

The Endpoint for Frontend

Summary

Subdomains and Bounded Contexts

Subdomains

The Core Domain

The Supportive Subdomain

The Generic Subdomain

Bounded Context

Bounded Context Boundaries

BCs are important

What about One model to rule em' all

Other benefits

Summary

Sharing data between modules in modular monolith

Querying other modules’ data… meh

Separate Backend For Frontend

Frontend calls REST APIs and connects the data

Duplicating necessary data to build Views/Read models

Let's stop talking SQL

Unhealthy relation

Looking through the prism of what we currently know

Simple implementation of pessimistic concurrency in Entity Framework

Solution

Secure data in a single Multi-Tenant Database in 3 simple steps

Row Level Security

Security schema

Security predicate

Add a policy

Working with the data

Summary

3 things I like to keep in mind when unit testing

Focus on the behavior, not on the implementation

Test your tests

Don’t generalize early on

Start using fields in C#. Using properties is not a good habit and won't do you any good...

Summary

The Difference Between Single And First Methods In C# -Explained

Single

First

What if I told you there are few more options?

Find

Single or... default

First or... default

C# Loops Explained

However...

Are you learning C#?

Why did we use `eql?` instead of `==`