Translations of domain concerns architecture characteristics

Domain concern	Architecture characteristics
Mergers and acuisitions	Interoperability, scalability, adaptabilitym, extensibility
Time to market	Agility, testability, deployability
User satisfaction	Performance, availability, fault tolerance, testability, deployability, agility, security
Competitive advantage	Agility, testability, deployability, scalability, availability, fault tolerance
Time and budget	Simplicity, feasibility

References

• Fundamentals of Software Architecture by Mark Richards, Neal Ford (2020)

How to detect changes by using Git

In various scenarios, you need to know what files were modified by a developer in your feature or main branch. Knowing which files were modified, you can determine which modules were impacted.

For example, you have a test suite that can take hours to run, and now you are running it in your deployment pipeline on each file change. The benefit of such an approach is that you can guarantee the quality of your product and ensure that your code change doesn't break existing functionality. Still, it hurts your productivity and the possibility of delivering new features quickly.

A solution for this problem could be to run only tests associated with a specific module. Git can help here. You can use the git diff command to get changes.

The first command will produce a diff between two commits:

git diff --name-only <commit>..<commit>

The second command will find diff from their common ancestor.

git diff --name-only <commit>...<commit>

New Version

If you want to get files modified in a new version, run this command:

git diff --name-only v1.0.0..HEAD

The result should look like this:

readme.md
src/package1/config.json
src/package2/config.json

Feature branch

If you want to get files modified in a branch feature, run this command:

git diff --name-only master...HEAD

The result should look like this:

src/package3/config.json

References

• https://initialcommit.com/blog/git-diff

Microservice

Microservices are an approach to distributed systems that promote the use of finely grained services that can be changed, deployed, and released independently.

Key Concepts of Microservices

Independent Deployability

Independent deployability is the idea that we can make a change to a microservice, deploy it, and release that change to our users, without having to deploy any other microservices. To ensure independent deployability, we need to make sure our microservices are loosely coupled: we must be able to change one service without having to change anything else. This means we need explicit, well-defined, and stable contracts between services.

Modeled Around a Business Domain

By modeling services around business domains, we can make it easier to roll out new functionality and to recombine microservices in different ways to deliver new functionality to our users.

Owning Their Own State

This gives the microservices the ability to decide what is shared and what is hidden, which allows us to clearly separate functionality that can change freely (our internal implementation) from the functionality that we want to change infrequently (the external contract that the consumers use).

Microservices embrace the concept of information hiding.1 Information hiding means hiding as much information as possible inside a component and exposing as little as possible via external interfaces.

Architecture

 A layered architecture is used to build applications based on domain-driven design. It consists of three main layers:

• Domain
• Application
• Infrastructure

Domain Layer

A domain layer is used to encapsulate the domain model and its behavior. The domain model should not depend on anything else and it should be agnostic to the technicalities of the clients it serves and data stores that persist in the domain objects.

Application Layer

The application layer is used to process business use cases.

Infrastructure

The infrastructure layer is concerned with purely technical capabilities.

Domain Service

Domain service is used to encapsulate business logic, which could not sit comfortably within an entity or aggregate in the system. Usually, a domain service is created then multiple entities are involved and behavior can't be owned by a single entity.

Characteristics

Every domain service has to match such characteristics:

• Represent behavior
• Stateless
• No identity

public class PricingService : DomainService, IPricingService
{
    public Money CalculateTotalPriceFor(IList<item> items, Coupon coupon) 
    {
        // ...
    }
}

Application Service

Application services are used to implement the use cases of an application. They do not contain business logic. They are responsible for orchestration, for hydrating domain objects from a database and mapping.

The main difference between application service and domain services is that domain service holds domain logic where application services don’t.

public interface ProfileService : ApplicationService, IProfileService
{
    public Task<Profile> CreateProfileAsync(string username)
    {
        // ...
    }

    public Task<Profile?> GetProfileAsync(int id, CancellationToken cancellationToken)
    {
        // ...
    }
}

Application services are similar to ASP.NET  Core controller actions. Controller actions contain logic to control the user interface interactions in the same manner that application services contain logic that represents business tasks or use cases that coordinate communication with services and objects within the domain layer.

In case then ASP.NET  Core controllers are used, there is no need to created dedicated application controllers. Controllers can be used as application services to implement use cases of an application.

As an alternative, commands can be used to process business use cases.

Infrastructure Service

Infrastructure Services is used to abstract technical concerns. The are responsible notifying other systems of changes in domain state via messaging systems or web calls, authorization, and logging.

public class MailService : InfrastructureService, IMailService
{
    public virtual async Task SendMailAsync(MailMessage mailMessage)
    {
        // ...
    }
}

Value Object

One of the domain modeling building blocks is a value object. Value objects are an entity's state, describing something about the entity or the things it owns.

Value objects are always preferred over entities because they are immutable and lightweight. Due this reason, it is easy to work with them.

In the .NET world, records are good candidates to implement value objects. Below, you can see how a value object can look implemented in C#.

public record Money
{
    public decimal Amount { get; init; }

    public Money(decimal amount)
    {
        if (amount % 0.01m != 0)
        {
            throw new ArgumentException("More than two decimal places", nameof(amount));
        }

        Amount = amount;
    }

    public Money Add(Money value)
    {
        return new Money(Amount + value.Amount);
    }

    public Money Substract(Money value)
    {
        return new Money(Amount - value.Amount);
    }
}

Characteristics

Every value object has to match such characteristics:

• Identity-Less
• Attribute-Based Equality
• Immutable
• Behavior-Rich
• Self-Validating

Now let's dive deep into each value objects characteristics. 

Identity-Less

Value objects have no identity.

Attribute-Based Equality

Value objects are considered equal if they have the same value.

var a = new Money(10M);
var b = new Money(10M);

Console.WriteLine(a == b); // True

Immutable

Once created, a value object can not be changed.

var a = new Money(10M);

a.Amount = 12M; // Can't be assigned

Behavior‐Rich

As much as possible, value objects should expose expressive domain‐oriented behavior and encapsulate the state.

var a = new Money(10M);
var b = a.Substract(new Money(2M));

Console.WriteLine(b); // Money { Amount = 8 }

Self‐Validating

Value objects should never be in an invalid state.

var a = new Money(10.0348M); // Throws exception "More than two decimal places"

Dependency Injection in JavaScript

Everyone who is coding with .NET, Java or PHP has heard about dependency injection (DI) or about inverse of control (IoC) or is using special framework which implements IoC/DI pattern. IoC and DI can be considered as synonyms. Recently applications written in JavaScript may consist of thousands of code lines and question may occur “Can dependency injection pattern be used in JavaScript”?

Before answering the question, lets figure out what is dependency injection and what are advantages and disadvantages of it.

Dependency injection is a software design pattern that allows to remove hard-coded dependencies and makes it possible to change them. Dependencies can be injected to the object via the constructor or via defined method or a setter property.

Advantages:

• Dependency Injection decreases coupling between an object and its dependency
• Dependency injection doesn't require any change in code behaviour, it can be applied an existing code
• Dependency injection helps isolate the client from the impact of design changes and defects
• Dependency injection allows the system to be reconfigured without changing the existing code
• Dependency injection allows concurrent or independent development
• Dependency injection allows to make code more maintainable and testable, because dependencies’ impact can be removed by replacing dependencies with mocks or stubs

Disadvantages:

• When instantiating type you have to know which dependencies to use
• Hides type’s instantiation and dependency resolving logic and if error happens, it can be much harder to figure out what's wrong
• It can require to write more lines of codes
• It can be slower when instantiating a type with keyword new, it’s related to meta data which has to be used while resolving instance

It’s time to move from theory to practice. Let's take a simple example. In this example we have driver who owns a car and the car can have one engine. 

Let’s write some code which implements defined class diagram above.

  function Engine() {
    this.hp = 256;
  }

  Engine.prototype.start = function () {
    console.log("Engine with " + this.hp + " hp has been started...");
  }

  function Car() {
    this.name = "wv";
    this.engine = new Engine();
  }

  Car.prototype.start = function () {
    if (this.engine) {
      this.engine.start();
    }
  }

  function Driver() {
    this.name = "tom";
    this.car = new Car();
  }

  Driver.prototype.drive = function () {
    if (this.car) {
     this.car.start();
    }
  }

  var driver = Driver();
  driver.drive(); 

  // Engine with 256 hp has been started...

From the first view everything looks OK. This code works. If you don’t need to test it or to change it in the future, this is code is fine. However, this code has some issues, one of which is that dependencies are hard-coded.

  function Engine(hp) {
    this.hp = hp;
  }

  Engine.prototype.start = function () {
    console.log("Engine with " + this.hp + " hp has been started...");
  }

  function Car(name, engine) {
    this.name = name;
    this.engine = engine;
  }

  Car.prototype.start = function () {
    if (this.engine) {
      this.engine.start();
    }
  }

  function Driver(name, car) {
    this.name = name;
    this.car = car;
  }

  Driver.prototype.drive = function () {
    if (this.car) {
     this.car.start();
    }
  }

  var driver = Driver("tom");
  driver.car = new Car("wv", new Engine(256)));
  driver.drive(); 

  // Engine with 256 hp has been started...

We have modified our existing code and it is extensible, but driver’s creation procedure has become more complex. In this case dependency injection container can help us. You can define driver’s details in configuration and when you want to instantiate driver you have to do it using dependency injection resolver. In the example below di4js library is used.

  di
    .register('engine')
      .as(Engine)
        .withConstructor()
          .param().val(256)
    .register('car')
      .as(Car)
        .withConstructor()
          .param().val('wv')
          .param().ref('engine')
    .register('driver')
      .as(Driver)
        .withConstructor()
          .param().val('tom')
          .param().ref('car');

  var driver = di.resolve('driver');
  driver.drive(); // Engine with 256 hp has been started…

As I mentioned before, that dependency injection may required to write more code as we can see in this example, on the other hand, there is one advantage that configuration is defined in a single place and it can reconfigured without changing the existing code base.

Autowire

If you do not want to define all dependencies manually, there is a solution. You can enable autowired option. If it is enabled for dependency resolver, all type's or instance's dependencies are resolved automatically by names. It may reduce the amount of code necessary to register types and their dependencies. With autowired option enabled you have to register only types. By default autowired is disabled.

Let’s simplify the example in order to show how autowired option works.

  function Engine() {
  }
  
  Engine.prototype.start = function () {
    console.log("Engine has been started...");
  }
  
  function Car() {
    this.engine = null;
  }
  
  Car.prototype.start = function () {
    if (this.engine) {
      this.engine.start();
    }
    console.log("Car has been started...");
  }
  
  di
    .autowired(true)
    .register('engine')
      .as(Engine)
    .register('car')
      .as(Car);
  
  var car = di.resolve('car');
  
  car.start();

We are going to see such output in console.

  "Engine has been started..."
  "Car has been started..."

One more and the most common scenario is mixed mode. By default you can allow to resolve dependencies automatically but some dependencies can be defined manually. Manually defined dependency has bigger priority.

If you are using different naming convention from the one given in the example it can be overridden easily. For more details read di4js documentation.

List of Dependencies

In some situations you may need to resolve a list of dependencies. To achieve this you have to make multiple registrations for single name.

Let’s modify our previous example and let’s say that driver can own more than one car at the same time which one to drive. Modified class diagram can be found below.

First of all we need to modify driver’s definition. Property ‘car’ has to be renamed to ‘cars’ and additional parameter ‘name’ has to be added to method ‘drive’. Let’s look to our modified source code.

  function Driver(name) {
    this.name = name;
  }
  
  Driver.prototype.drive = function (name) {
    if (this.cars && name) {
      if (this.cars instanceof Array) {
        for (var i = 0; i < this.cars.length; i++) {
          if (this.cars[i].name === name) {
            this.cars[i].start();
            break;
          }
        }
      } else if (this.cars.name === name) {
        this.cars.start();
      }
    }
  }

It’s time to register driver’s dependencies and try to resolve it.

  di
    .register('engine')
      .as(Engine)
        .withConstructor()
          .param().val(256)
    .register('car')
      .as(Car)
        .withConstructor()
          .param().val('wv')
          .param().ref('engine')
    .register('car')
      .as(Car)
        .withConstructor()
          .param().val('ford')
          .param().ref('engine')
    .register('tom')
      .as(Driver)
        .withConstructor()
          .param().val('tom')
        .withProperties()
          .prop("cars").ref('car');

To instantiate driver by name we need to write a single code line.

  var tom = di.resolve('tom');

If we invoke method ‘drive’, we will get results which will be printed to console output.

  tom.drive('wv');

  // Engine with 256 hp has been started…
  // Car 'wv' has been started...

Using setter methods instead of properties / fluent interface

There is one more fancy feature. Some objects do not have properties, they have only setter methods and fluent interface. Such scenario with di4js library can be handled too. There is one limitation that these dependencies can not be resolved automatically.

Let’s modify our previous example and replace properties with setter methods.

New defined methods look like this.

  Car.prototype.setEngine = function (engine) {
    this.engine = engine;
    return this;
  };
  
  Driver.prototype.setCars = function (cars) {
    this.cars = cars;
    return this;
  }; 

Below you can see how modified type and its dependencies registration look.

di
  .register('engine')
    .as(Engine)
      .withConstructor()
        .param().val(256)
  .register('car')
    .as(Car)
      .withConstructor()
        .param().val('wv')
      .withProperties()
        .func('setEngine')
          .param().ref('engine')
  .register('car')
    .as(Car)
      .withConstructor()
        .param().val('ford')
      .withProperties()
        .func('setEngine')
          .param().ref('engine')
  .register('tom')
    .as(Driver)
      .withConstructor()
        .param().val('tom')
      .withProperties()
        .func('setCars')
          .param().ref('car');

If we resolve driver and invoke its method ‘drive’, we will get the same result as in previous examples.

Child container

In all examples global dependency resolver is used, it’s good for demo purposes and small apps. For bigger apps child dependency resolvers should be created per scope. It allows to get better flexibility and extensibility. Parent can be extended or overridden by child without making an impact on it.
First of all let’s register type in global dependency resolver and then try to resolve registered type by name.

  var DieselEngine = function () {
  };
  
  DieselEngine.prototype.start = function () {
    console.log("Diesel engine has been started...");
  };
  
  function Car(engine) {
    this.engine = engine;
  }
  
  Car.prototype.start = function () {
    if (this.engine) {
      this.engine.start();
    }
    console.log("Car has been started...");
  }
  
  di
    .autowired(true)
    .register('engine')
      .as(DieselEngine)
    .register('car')
      .as(Car);
  
  var car = di.resolve('car');
  car.start();

We are getting such results.

 "Diesel engine has been started..."
 "Car has been started..."

Now we can create a child container from the parent and then try to resolve overridden type.

  var PetrolEngine = function () {
  };
  
  PetrolEngine.prototype.start = function () {
    console.log("Petrol engine has been started...");
  };
  
  var child = di
    .create()
    .register('engine')
      .as(PetrolEngine);
  
  car = child.resolve('car');
  car.start();

Now we are getting different results.

  "Petrol engine has been started..."
  "Car has been started..."

Injection to function or object

There is a situation when instance creation can’t be controlled by dependency injection resolver. This situation may occur when you are adapting dependency injection for legacy code or instances are created by other components which you do not control. There is an option to inject dependencies to object or to function.

The first example demonstrates how dependencies can be injected to the function using parameters’ names.

  
  di.inject(function (car) { 
    car.start();
  });

In the second example an array notation is used to inject dependencies to the function.

  
  di.inject(['car', function (car) { 
    car.start();
  }]);

In the following examples I have demonstrated how to inject dependencies to the function. In following examples I am going to demonstrate how dependencies can be injected to an object.

  
  var car = new Car();
  di.inject(car);
  
  car.start();

There is the second method how to inject dependencies to object. You have to provide registration name which has to be used while injecting dependencies.

  
  var car = new Car();
  di.inject(car, 'car');
  
  car.start();

AMD

di4js is compatible with asynchronous module definition (AMD) and it can be loaded as ordinal module.

  
  define(['di4js'], function (di) {
    
    function Engine(hp) {
      this.hp = hp;
    }
  
    Engine.prototype.start = function () {
      console.log("Engine with " + this.hp + " hp has been started...");
    }
    
    di
      .register("engine")
        .as(Engine)
          .withConstructor()
            .param().val(256);
    
    var engine = di.resolve("engine");
    
    engine.start();
  
  });

Testing

As I mentioned before, if you are using dependency injection your code is maintainable and testable, because dependencies can be replaced with stubs or mocks easily.

In the following example I am going to use a well known testing framework Jasmine. I am going to demonstrate how we can test single method replacing dependencies with mocks.

  
  describe("car", function() {
    it("should start a car", function() {
      
      var engineMock = jasmine.createSpyObj('engine', ['start']);
      
      var car = new Car(engineMock);
      car.start();
      
      expect(engineMock.start).toHaveBeenCalled();
      
    });
  });

As we can see in the example such code can be tested easily.

Why di4js?

di4js is lightweight library which is inspired by Unity, Spring, AngularJS and others. di4js advantages are that it is a small library and it’s dedicated to solve a certain problem, thus it’s not a massive framework which tries to cover everything. It also doesn’t depend on other libraries, so it’s easy to embed it to an existing code base.

You may ask why it was created. The answer is simple. A range of libraries have been investigated and none of them satisfied expectations. The goal was to gather various components from various libraries to a single place. Initially it was written for internal purpose but now a decision has been made to share it. Maybe it will be useful for others too.

di4js can be used in projects which are not build on big frameworks such as AngularJS, because big frameworks have built in solution for dependency management. di4js can be useful when you depend on small dedicated libraries.

Usage

di4js library is released under MIT license. It can be used in modern browsers or in other JavaScript runtimes such as Node.js. Library can be installed from various package managers: nuget, npm or Bower.

To install di4js module for Node.js, this command should be used:

  npm install di4js

To install di4js for web browser, run the following command:

  bower install di4js

In Visual Studio di4js module can be installed using NuGet extension. To install di4js, run the following command in the package manager console.

  Install-Package di4js

If you want to look at the source code or to get more information about library or its usage, just vist https://github.com/gedbac/di4js.

Final thoughts

At the beginning we asked a question “Can dependency injection pattern be used in JavaScript?”. Now we can answer to that question and say that dependency injection can be easily used and is useful in JavaScript, but project size and complexity always has to be considered. Thus, problem has to be identified and after that corresponding solution has to be chosen. Consequently, we can say that every pattern which is used in other languages can be easily adapted to the JavaScript.