Software Quality

As you may know, I’m working on an open source project called Visual MASM which is an IDE to create assembly applications for Windows just as easy as the Delphi or Visual Studio IDEs provide. Well, at least that is my goal.

I was looking back on why I want to create a commercial application in the Real Estate industry using my very own assembler IDE and was reading what I wrote about using assembly in the first place: Why Assembler?

There are so many languages and tools available today in order to program a solution. I have used almost all of them in the past 32 years of programming. Why on earth use assembly for Windows? For a clear business reason, Windows “owns” the world wide market and is used in over 90% of computers as of today. Never mind Linux, MacOS, etc. I mean, Windows “owns” it. Period. It makes total sense to develop for Windows when you create a commercial solution.

The fact that Windows owns the market; however, is still secondary to my motivation to create a commercial application for Windows using the assembly language. The main reason is really: Software Quality.

Quality in general, in my opinion, means paying attention to every detail. Because one pays attention to every detail, you are forced to make many decisions. As you abstract into higher languages, these decisions have been made for you. Because of this, you are no longer able to make detailed decisions. In order to pay attention to the detail of software quality, you have passion to follow through with it. Being able to make these detailed decisions also offers freedom and control of the creation process. That’s the ultimate power of high, software quality. You must have control in order to make software quality decisions.

So, paying attention to detail with passion is equivalent to high software quality. It is that simple.



Creating IDs with CQRS and Event Sourcing in Java and .NET

I’m currently working on a cloud-based system that uses microservices with domain driven design and CQRS and Event Sourcing in Java. I love C# and .NET but I decided to do this in Java for several reasons. This could have been done in C# just as well. In fact, this system is a mix of some C# microservices and Java microservices. The important thing is that we are using the same concepts that are applicable when doing DDD and CQRS and Event Sourcing.

Anyways, I wanted to put down my thoughts on what I have been thinking about since last week and I hope this might be useful to anyone who came across the same question. So, my question since last week was this:

“Who creates an entity id in DDD when doing CQRS and Event Sourcing?”

Well, the way I have been doing this was as follows:

  1. When an application service executes a use case via one of its methods, it can create a new entity via a new immutable value object. All my entities’ ids are immutable value objects.
  2. Sometimes, a factory in the domain model creates new entities. Again, the entities’ ids are created via immutable value objects.
  3. Sometimes, a domain service creates new entities with immutable value objects.

This is all fine and good. I started to look at Greg Young‘s sample C# project at his Github here. For this who do not know him, he is a fantastic speaker and mentor for CQRS and Event Sourcing. Check out his videos, papers, and blog posts. Excellent material. He has a free 6 hour video here. And, while you are at it, check out his video about: “7 Reasons Why DDD Projects Fail“.

What poked my interest was this particular line in his CreateInventoryItem command code:

public class CreateInventoryItem : Command {
    public readonly Guid InventoryItemId;
    public readonly string Name;

    public CreateInventoryItem(Guid inventoryItemId, string name)
        InventoryItemId = inventoryItemId;
        Name = name;

If you look closely on line 5, you will see that the entity id inventoryItemId is being passed as part of the CreateInventoryItem command. This is a small but important detail.

I had an interesting thread discussion with Greg Young about this here. Greg raised a few good questions:

  1. What about when you want to send 3 commands?
  2. How will you start returning ids from commands?
  3. What if a command creates 3 entities?
  4. How will the domain get those ids back to the client?
  5. My UI is creating an account then the next step is managing some details. How does the UI go from one step to the next without knowing the account id?

As you can see, there are several good reasons why a client would want to create the ids instead of the domain model. Another reason I would want to add to this is that if the domain would create the ids, it would violate the goal of keeping track of all state changes in domain events with the commands as the initiators. In my opinion:

In a CQRS based system with Event Sourcing, commands carry all attributes that are required to execute the command including the creation of identities.

So, a client can create a command with ids that are based on Guids/Uuids and then send these creation commands with those ids. This allows you to do things such as persisting the commands and being able to replay those commands as well with 100% accuracy because the domain model with arrive every time to a deterministic state when you replay the domain events.

I like this very much and it provides a lot of freedom with inductive UIs / task based UIs.

Modeling Aggregates in DDD

Here are a few notes I wanted to point out when you are trying to model aggregates in domain driven design (DDD). Many times I can’t find the right words or I simply forget what the technical definitions are when you model your domain model or any parts of a domain model such as aggregates. I always go back to the fantastic book “Implementing Domain Driven Design” by Vaughn Vernon. He is a master in showing and explaining it in such a way that I can not do a better job. As I’m currently doing some modeling work over the weekend, here is a summary from how Vaughn is explaining it:

When trying to discover the Aggregates in a Bounded Context, we must understand the model’s true invariants. Only with that knowledge can we determine which objects should be clustered into a given Aggregate.

He talks of how you should design your aggregates. What does an aggregate consist of. So, he goes on with another perfect explanation:

“An invariant is a business rule that must always be consistent.”

Followed by another super explanation:

“Aggregate is synonymous with transactional consistency boundary.”

In the past, I made the mistake of clustering aggregates via composition: “This object A contains object B” which is wrong. Once you understand the bounded context and the aggregate’s true invariants (the business rules), you got it. You hit the jackpot. The light will come on.

Anyways, I wanted to publish this for some time now but never bothered since I always go through Vaughn’s book. But, I thought others might find this useful information especially if you are doing domain driven design and microservices.

Big Data Analysis vs. Big Picture Analysis

I’m sure you have heard the buzzwords around Big Data and Big Data itself. Companies and governments are gathering lots and lots of data about lots of things. Big Data analysis is trying to make sense of this mountain of data and let people make intelligent decisions. It is this Big Data analysis itself I have a problem with. To be more specific, the problem I see is when people are trying to do Big Data analysis without seeing the big picture first. I guess I would call this a “Big Picture Analysis” when you do have all the data at hand but also the reasons “why” you have so much data in the first place.

Let me explain.

Say you have a system or maybe even many computer systems that generate data that you want to analyze at some point in the future.  You may or may not know how you want to analyze all this stuff but you do know that it might come in handy, one day. So, you store a ton of information. By that, I mean the system stores a ton of information into database, log files, etc. Most of the time, you don’t let the system delete anything. You just let the system gather more and more information because storage space is cheap in AWS.

Let’s assume you decided to look inside this mountain of data because you, or the business rather, can take advantage of this data to learn more about your customers and hopefully sell more products and/or services this way.

When you look inside your mountain of data using the latest Big Data analysis tools, you discover certain facts and statistics. You gather, you sum up things, and divide, you formulate, you massage the data, and so on. At some point, you will need to put these analysis results into some form of presentation that can be further used to make decisions. This can be reports, dashboards, etc.

Now, here comes the crux. With all this mountain of data, how can you be certain why you have all this data in the first place? I mean, why did your system(s) store all this data? Obviously, it stored all this data because it was designed to store all this data into databases etc. But, i’m trying to get you to see this from a business point of view. If you have modeled your system based on the domain, then you should be somewhat familiar with the data that was stored in the database. When you have a domain expert look at some of the data, that person might see certain indicators of what this data is about. Or, that person might have no clue even though that person is a business expert, a domain expert.

My point is that when you look at Big Data you should also look at the reasons why this Big Data exists. Only then, you can make a full connection and see the “Big Picture”. When you see the cause for the Big Data to exist, you can make better assumptions and conclusions after you have completed the analysis. You will be able to follow the “thread” from start to end. When you create a report after you have completed your Big Data analysis, you should also see the causes side by side on that report. Only then, you can see the Big Picture.

So, how do you do that? If you are a big fan of domain driven design (DDD), then you are almost there. When you model a domain you also model domain events (most of the time). Domain events reflect a significant event that has happened inside your domain. The past tense is important here. Things have happened already. Domain events capture these events and let you store that these significant domain events have happened. This is when things get very exciting. Imagine what you can do here. Your domain model not only operates on the business domain but also allows you to record of anything interesting that was triggered for business reasons. When you take a look at your recorded domain events at certain dates and times, you can connect your mountain of data and the reasons why this mountain of data was born. The domain events are the reasons why you have so much data. Your reports can reflect and show this connection between domain events and stored data.

At the end, your analysis just received a significant confirmation and validation of having more accurate information. This leads to an even better understanding of the data and ultimately making smarter decisions for those who need this information.