Domain Driven Design with Web API revisited Part 5: starting with the domain in code

Introduction

In the previous post we discussed the concept of ubiquitous language in DDD. It describes the problem domain in clear terms that are well-known for each stakeholder in the project. Each bounded context has its own well defined ubiquitous language that all parties stick to in every form of communication. We also defined the most important terms and rules for load testing bounded context of our demo application.

In this post we’ll start coding the domain objects. My intention is to be as detailed as possible as the domain layer is the most important on in a DDD project. Therefore this section will span two blog posts.

Read more of this post

Calculate standard deviation of integers with C# .NET

Here comes a simple extension method to calculate the standard deviation of a list of integers:

public static double GetStandardDeviation(this IEnumerable<int> values)
{
	double standardDeviation = 0;
	int[] enumerable = values as int[] ?? values.ToArray();
	int count = enumerable.Count();
	if (count > 1)
	{
		double avg = enumerable.Average();
		double sum = enumerable.Sum(d => (d - avg) * (d - avg));
		standardDeviation = Math.Sqrt(sum / count);
	}
	return standardDeviation;
}

Here’s how you can call this method:

List<int> ints = new List<int>() { 4, 7, 3, 9, 13, 90, 5, 25, 13, 65, 34, 76, 54, 12, 51, 23, 3, 1, 7 };
double stdev = ints.GetStandardDeviation();

View all various C# language feature related posts here.

A common platform for concurrent bags, stacks and queues in .NET

We’ve looked at the available concurrent collections in .NET before:

3 of these objects implement the same interface. Can you guess which three are similar in some sense? Stacks, bags and queues differ from dictionaries in that elements in those collections cannot be retrieved by an index of any sort. You can take/pop/dequeue the elements one by one but you cannot get to element #3 without first removing all elements before that.

Read more of this post

Domain Driven Design with Web API revisited Part 4: the ubiquitous language and our refined problem domain

Introduction

In the previous post we went through a couple of important terms in DDD and also started coding the foundations of the web suite demo app. In particular we discussed the meaning of bounded contexts and the shared kernel. Each domain object will be defined within a specific context, e.g. the load testing context and the web monitoring context as mentioned previously. There may be some sections where the contexts overlap. These sections are contained within the shared kernel that each bounded context can refer to. Finally we started building our code and introduced abstractions for the entities, value objects and aggregate roots.

In this post we’ll first introduce the concept of ubiquitous language and then sort out the key terms that describe our problem domain.

Read more of this post

Python language basics 39: string formatting

Introduction

In the previous post we looked at the usage of the partition function. It can be applied to strings and it breaks up strings into 3 parts: to the left and the right of the partitioner and the partitioner itself. It is similar to the split function.

In this post we’ll briefly go through formatting strings with the format function.

Read more of this post

Python language basics 38: how to partition a string

Introduction

In the previous post we looked at the split function that operates on strings. We saw how it could split up a string into its elements using a delimiter.

In this post we’ll look at the partition function of the string type.

Read more of this post

Explicit interface implementation in .NET Part 4

In the previous post we finally solved the mystery of how the Add method was “hidden” in the ConcurrentDictionary object. We now know how explicit interface implementation works in code.

However why would you implement an interface explicitly?

Read more of this post

Domain Driven Design with Web API revisited Part 3: shared kernel, bounded context and some initial code

Introduction

In the previous post we discussed 3 fundamental concepts in DDD: entities, value objects and aggregates with aggregate roots. We said that an entity is an object whose identity is defined by its ID key for the purpose of tracking its state through time. Its properties can change but its ID – whether a simple integer or a composite – should never be modified after the object has been created. Value objects on the other hand are defined by their properties and are immutable. We can say that a value object is also a type of entity but its ID is a composite of all its constituent properties. As the IDs are immutable per se, value objects are consequently also immutable. Finally, aggregates are groups of objects that are treated as a unit for purposes of data persistence. The “boss” of the group is the aggregate root and it’s through the aggregate root that other aggregates communicate with other aggregates.

In this post we’ll look at a concept called the shared kernel and how the above mentioned concepts can be represented in code.

Read more of this post

Explicit interface implementation in .NET Part 3

In the previous post we started looking into how explicit interface implementation is done in code. Visual Studio makes it a breeze and you can easily produce code like we saw previously:

int IMultipliable.Calculate(int a, int b)
{
	...
}

So now we can reach the Calculate methods as follows:

Read more of this post

Explicit interface implementation in .NET Part 2

In the previous post we introduced the idea of explicit interface implementation in .NET. We also saw two examples from .NET with explicit implementation in action.

Let’s first see how this language structure works in C#. Suppose we have the following interface:

public interface ISummable
{
	int Calculate(int a, int b);
}

We can then implement this interface implicitly as follows:

public class Calculator : ISummable
{
	public int Calculate(int a, int b)
	{
		return a + b;
	}
}

This should be straightforward for all programmers.

Let’s have another interface:

public interface IMultipliable
{
	int Calculate(int a, int b);
}

We then want our calculator to implement the above interface as well:

public class Calculator : ISummable, IMultipliable
{
	public int Calculate(int a, int b)
	{
		return a + b;
	}
}

As Calculator already has a Calculate method with two integer parameters it also satisfies IMultipliable without changing the Calculator object implementation.

This is problematic as we have no straightforward way to provide a multiplication for our calculator:

Calculator calculator = new Calculator();
int res = calculator.Calculate(2, 5);

“res” will be 7 of course.

We assume here that we cannot change the method names of ISummable and IMultipliable. They may be part of a third party library. One way out of this situation is to implement IMultipliable explicitly. If you right-click “IMultipliable” in Calculator.cs in Visual Studio you can select “Implement Interface”, “Implement Interface Explicitly” in the context menu. You’ll get the following stub:

public class Calculator : ISummable, IMultipliable
{
	public int Calculate(int a, int b)
	{
		return a + b;
	}

	int IMultipliable.Calculate(int a, int b)
	{
		throw new NotImplementedException();
	}
}

The structure of the new Calculate method looks very much like the non-generic GetEnumerator method of the second example of the previous post.

Explicitly implemented interface methods must not have any access modifiers. They are public by default.

Let’s implement the new method:

int IMultipliable.Calculate(int a, int b)
{
	return a * b;
}

How can we call this method? We have to declare Calculator as an interface type:

public void ShowSample()
{
	IMultipliable calculator = new Calculator();
	int res = calculator.Calculate(2, 5);
}

“res” will now be 10.

We’ll investigate this further in the next post.

View all various C# language feature related posts here.

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

ARCHIVED: Bite-size insight on Cyber Security for the not too technical.