World of Warcraft Classic – A technical and business analysis


First of all, I’m super excited that Blizzard announced a “Classic” version of WoW. I don’t even care about the new expansion “Battle of Azeroth”. I quit WoW about 1 ½ years ago because I was very much bored in doing the mindless, dumb down, and very repetitive expansions. I normally don’t post about games here but I have always enjoyed great games and being able to immerse yourself into different worlds is just cool. I’ve always been interested in how games are made as well.

In the last few days, I have read and watched several reactions of the WoW community on WoW Classic and the topic of Vanilla WoW in general. Lot’s of people are speculating on how and especially when this could play out. Everything I have heard and read about is pretty much based from a consumers’ point of view, the players point of view. I didn’t hear anything about why and how Blizzard can do this. We all know from the announcement that “it will take some time”.

However, I wanted to share with you the possible reasons why Blizzard decided to go this route of planning to release a Classic version of WoW. In addition, and more importantly, I wanted to provide you guys into a view of how Blizzard can do this from a technical point of view and what it would take to pull this off. This would help arrive at possible timelines and a possible number of players buying WoW Classic versus how many players will buy the new expansion and even making some other predictions.

Please keep in mind that what I’m about to present to you are my own speculations based on many years of technical expertise in creating and supporting small to very large software systems. I don’t want to bore you to death but I do want to point out my qualifications at least on the technical side to be able to give you an idea of what it would take for Blizzard to do this.

My qualifications

On my technical experience, I have been programming since 1985 and still do actively today. I’m a hands-on software architect working for a very large company. I’m currently in charge for a world-wide development and deployment project that is taking 2 years in the planning and active development. I’ve been in 10 different software industries ranging from real-estate, to banking, to healthcare, to automotive, to criminal justice, to aviation, and more. I can program in multiple languages and still do today from assembly (x86 mostly, even today) to high-level languages such as C (yes, C is high level when compared to assembly), to Java, to C# and others. In short, I’m a hands-on architect who designs, comes up with solutions and can also program it to the end. I also started several companies and still have a start-up company which is a cloud-based, world-wide Software as a Service (SaaS).

On my business side of things, I have great experience on what people really want but can not really express it simply because, software is hard as heck. I’m running a successful cloud-based software start-up while working for a large company. It’s running 24/7 world-wide without having us to intervene much because it was designed like that. Simple. I know what it takes to run a software company. Programming is just one portion of it. There are many other things to worry about in order to get software into the hands of consumers. This is one of those things I wanted to share with you.

Having said all that, this of course, still does not qualify me to speak for Blizzard since I do not and never did work for Blizzard and I’m not being endorsed in any way either. I have never seen any information about the internals of keeping the lights on and on how to be able to run WoW either. These are simply my own opinions. So, take it with a grain of salt.

What is WoW Classic?

At first, this should be easy to answer, right? Not so, it depends on who you ask. Let’s ask some players who are big fans of the Vanilla version including myself. I would assume this is what Classic would mean to them (correct me if I’m wrong in the comments below and I’ll update here).

Player’s point of view:

  1. Exactly the same game as Vanilla from 2004
  2. None of the new expansion features are “added-on” like LFG, etc.
  3. Literally the same game as if you would have bought it back in 2004
  4. The same computer system requirements as back in 2004
  5. Being able to access your characters for many years from now
  6. Perhaps some patches applied to fix bugs (we’ll come back to that one)
  7. Minus the bad launch experience (we’ll come back to that one)

So, from a consumer’s point of view, these seem very reasonable requests. However, there are technical challenges in which I will go into more detail later on.

Blizzard’s point of view:

  1. Additional revenue
  2. Additional revenue
  3. Additional revenue
  4. Let players access Vanilla 2004 content
  5. Let players experience the original game play
  6. Apply critical bug fixes
  7. Smooth roll-out with today’s hardware and software infrastructure, world-wide
  8. Smooth support
  9. Prolonged marketing and name recognition

This could be a definition of what WoW Classic could mean for Blizzard. For the why and how, read on.

Why WoW Classic?

Why would Blizzard announce a Classic version of WoW? Notice that Blizzard did not announce “World of Warcraft – Vanilla”. This could be just a marketing idea because “Classic” could mean many things such as:

  1. Original vanilla
  2. Original vanilla plus BC
  3. Original vanilla plus BC plus ROTLK
  4. Original vanilla plus BC plus ROTLK plus …
  5. Heavily modified game engine with Vanilla content
  6. Heavily modified game engine with Vanilla content plus expansions
  7. New game engine with vanilla content
  8. New game engine with vanilla content plus expansions over time
  9. etc.

As you can see, Classic could leave the door open to multiple options on what to deliver and what that really means. It buys some time as well. Back to why Blizzard would create a Classic version.

There are three obvious reasons and it makes perfect sense:

  1. Additional revenue
  2. Additional revenue
  3. Additional revenue

Blizzard is a company and needs to make money. As a company, you are not here to make friends, you are here to make revenue and keep increasing revenue whenever possible. This seems obvious but it is super important to keep this mind. Almost all decisions Blizzard is making drives around this fact. So, let’s look at the financial aspect of it.

Since 2004, Blizzard has gained monthly subscription accounts and peeked at 12 million accounts in the second half of 2010. However, since 2011, Blizzard has lost players over time by no longer paying the monthly $15 subscription fee. Each expansions introduced a slight peek but then the number of accounts fell shortly afterwards. It never again reached the 12 million subscriber number. At least that is what we know of since Blizzard no longer publishes these numbers for obvious reasons. Why tell anyone that you are loosing your core customers? This is not something you want to announce. You don’t want to tell potential future customers that your existing customers are leaving by the millions. This makes perfect business sense.

It is estimated that Blizzard currently holds around 4.5 – 5.5 active and paying WoW subscribers. Say we take a wild guess and estimating an average of 7 million subscribers on a yearly basis since 2004.

Revenue (avg):

$105,000,000 / month
$1,260,000,000 / year
$16,380,000,000 total, since 2004 (that’s 16$ billion)

This does not even include any of the add-ons such as transfers, gold, pets, etc. Pretty impressive, over 16$ billion in revenues based on a game. At first, it does look great. However, let’s take a closer look on trying to gain more revenue for a company, rather lost revenue.

You gain some, you loose some. That is normal. Players stopped playing even in 2005, we just don’t know those numbers because all we heard how WoW was taking over since 2004. But, let’s just take a look at the falling numbers since 2011. That is 7 years of lost revenue for many, many reasons. If we assume that Blizzard could have held the 12 million accounts since 2010 until today, Blizzard should have generated:

$2,160,000,000 / year

but it didn’t so we assume the $1,260,000,000 / year number. That is a lost revenue of 900$ million per year. That is a lost revenue of:

$6,300,000,000 total revenue loss

That is more than 6$ billion in cash folks. This is some serious money. Like I said, there are many, many reasons of why these numbers fluctuate. Computer games in general are short-lived. There are many reasons why WoW is still the king of MMORPG’s though. I think we all know the reasons.

From a company’s point of view, I would say the question would be: “How can we recover this lost revenue?”. How could this be even increased and surpass any previous revenue records? These are the questions Blizzard should ask itself.

Another question would be, “How can we slow down or stop the decline of new and existing subscriptions?”

I’m not saying that Blizzard will ever reach 12 million subscribers again for sure. But you never know. I believe it is possible to reach 12 million subscribers again. Let me explain. Since 2011, Blizzard lost 5 million customers each year. I’m not talking about keep the same 5 million people across 7 years. That is just one part of it. That is 5 million core customers lost that includes any new players that Blizzard could have kept over the years. That is the ideal scenario.

I believe that Blizzard knows it can bring back at a minimum 5 million old customers back given the right conditions and timing. All you have to look at is the internal data of lost customers which we do not have access to.

  1. Prediction: 5 Million WoW Classic sales

My first prediction is that Blizzard will be able to sell, easily I might say, 5 Million WoW Classic copies of the game. That is roughly $100 million in revenue right there. If Blizzard requires to have active subscriptions, that would be $75 million per month or $900 million per year. That is 4.5$ billion in 5 years. That is some serious cash just from a Classic game.

I can tell you this from my experience, if I had roughly 1$ billion in almost guaranteed revenue per year, you bet I can solve all technical issues. More on that later.

Now comes the ripple effect. Even if those 5 million “returned” customers drop out and no longer play, because they have an active subscription, they might be interested in purchasing the latest expansion. Great for Blizzard. But, let’s be realistic for a moment. If Blizzard gains 5 million returned customers, how many would stick around to level 60? It’s hard to say but my guess would be that it would be the majority of those 5 million if you consider “Why” these customers are coming back.

  1. Prediction: 4 Million active WoW Classic subscribers month over month

So far, I gave you mostly the financial justifications. But there are other many other reasons why Blizzard would want to come out with a WoW Classic edition:

  1. End illegal legacy servers around the world because of the lost revenue and no longer have to spend legal costs to do so
  2. Make customers happy. This has a halo affect and drives many other sales within Blizzard’s offerings.
  3. Keep internal staff excited and stay with Blizzard. Like other companies, Blizzard needs to worry about keeping its top talent. This is an unspoken rule. Money won’t help here. People that work in the software industry want their work to be seen and excite others. That’s what it’s all about.
  4. Make WoW challenging and not dumbed down. Blizzard won’t be able to do this with the current version and would risk loosing existing customers. The Classic edition has that built in, free. You have to work your butt off and worry about a lot of aspects of the game in Vanilla. This is much more challenging than the current dumbed down WoW.
  5. Simply no longer have to deal with internal company debates of doing a Classic or not. This kind of energy can be put into the creative process of putting out a Classic edition. And also no longer have to deal with customers constantly asking for Vanilla.

I’m sure there many other reasons. Please let me know your thoughts and I’ll add them here.

What are the technical challenges?

First of all, I heard people saying that Blizzard may no longer have the source code. I can tell you right there with 100% certainty, that this is complete hogwash. Of course, Blizzard has the source code from the very beginning. As a software company, the source code is your bread and butter. You treat the source code like it is gold. It’s put away safely so the source code itself especially master source code is physically protected and multiple locations that very few people have access to. Blizzard has every bit of source code, I can guarantee this. So, let’s drop that myth right there.

Why is having the original source code important? Let me explain. Like it was announced, “We want to recreate the original Vanilla game experience but not the launch experience”. This exposes a lot of information to me. What this tells me are the following:

  1. Blizzard wants to utilize all of its experience acquired in creating and maintaining software
  2. Blizzard does NOT want to recreate bad experiences for its customers if preventable
  3. Blizzard wants to utilize modern software tools, techniques, and infrastructure
  4. Blizzard can not use the original source code the way it is if it wants to do any of the items above
  5. Blizzard must, at a minimum, modify existing server and client software if it wants to do any of the items above

I’m pretty sure Blizzard did its due diligence and analyzed the original source code and got a rough idea of how much work needs to be done to the server and client software before the announcement was made. Keep in mind there are four, large, technical components to make this work:

  1. Client software. This is the software you and I have installed on our computer
  2. Server software. This backend software we never see and is maintaining everything the the client software can not and should not do. For example, I’m not talking about just “one” physical server. This backend infrastructure has many servers working together around the world 24/7 and allows players to play the game wherever they are. It enables for players to see and talk to other players. And so many other things.
  3. Infrastructure. Back in 2004, the Internet existed but there was no cloud-computing concepts, yet. With today’s technology and the power of cloud-computing, it has changed pretty much everything we do today in software development. This is not just the software itself. This also includes networking infrastructure, security, maintenance of the servers in each region of the world, and so much more.
  4. Maintenance. Blizzard needs to backup and maintain the software and the more importantly players data such as your character information. The good news is, today’s storage capabilities in cloud-computing is dirt cheap. When compared to 2004, data storage is practically free in a cloud environment.

Here comes the interesting piece of why this will take some time for Blizzard to release a Classic edition.

  1. Blizzard will need to modify existing client software to take advantage of modern capabilities such as communicating differently to its server software than the way it did back in 2004’s version of the server software. This really depends on how the software is designed. Is it designed so co-mingled with infrastructure that it is hard to separate? Or, was it designed to easily replace certain parts of the software with other, newer parts? This is one of those difficulties of creating and maintaining software. Is it crappy software quality inside or is it high quality software. Only Blizzard knows.
  2. Blizzard will need to modify or even replace the server software. Blizzard wants to take advantage of modern infrastructure such as cloud-computing. There is a good chance that Blizzard can actually throw away old server code because cloud-computing components may already provide a lot of functionality that Blizzard had to create and maintain back in 2004. At a minimum, Blizzard will need to modify existing server software. This is probably the most important part of the entire WoW Classic edition. This piece must work really well and Blizzard will spend most of the time on this area.
  3. If the current resources working on the new expansion can not be used for this, Blizzard needs to hire additional staff under the guidance of the original, 2004 Vanilla team members. The great advantage Blizzard has here is that it knows how “not to do things”. What I mean by that is that because 13 years have passed, Blizzard must have learned an awful lot on what works and what doesn’t work. So, hiring top talent to get the job done also takes time. It’s not easy to find the best of the best. This really depends when Blizzard starting this process.
  1. Prediction: WoW Classic will be released 4th Quarter 2018.

Given the items above and given the capabilities of modern software and cloud-computing and the right number of top talent to work on this, I believe Blizzard can pull this off to release WoW Classic by the 4th Quarter of 2018.

Here we are, a few ideas and speculations from my end. Let me know your thoughts and if I’m completely off and gone crazy. I know we all want this happened by Christmas, 2017. But, that’s not going to happen, or will it? Haha.

I will see you in Classic.

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.


How to be a great programmer

I have been programming since I was 15 at 1985 starting on an Amstrad CPC 464 on 8-bit Z80 processor at a whooping 4 Mhz. The programming language used was Locomotive Basic for the Z80 processor. This is my first exposure to actually tell a computer what to do, and it did it by coding this:

10 Print "Hello"
20 Goto 10

It printed “Hello” on the screen and kept going. These simple lines woke up my passion and my amazement of the computer and it’s software. The computer did what I just told it to do, over and over. That was 32 yeas ago and I still love creating software, love seeing creativity transformed into something useful and beautiful at the same time.

The reason I’m telling you this is because I want to set the stage of what I have learned over the past 32 years on how to be a great programmer if you so desire. What I’m about to share with you are my own experiences and opinions.

Here are a few things that you either have or will gain over time as a great programmer:

You care

As with everything in life, if you care for something, you give it special attention. Now, programming a computer needs your special attention already because the computer will not allow for any mistakes simply because there are no gray shades. What I mean by that is that the computer is absolute, true or false. When you care, you pay special attention to the software you program. What does that mean? You care how you compose your pieces of code in whatever programming language you use. Is your code legible? Can you understand your code 6 months from now? What does the architecture look like? Have you even thought about it? How does any data flow between your methods and functions? Where does it start and where does it end? Can you follow the money within the programming code? Do you care enough to rename your variables and functions to something more understandable after requirements change? Do you care enough to reduce any technical debt meaning do you care enough to simplify your code to make it easy to maintain? Do you care enough to remove dead code? Do you care enough to be open for new ideas on how to do things differently than what you are used to? When you care, you pay attention to the smallest details. You pay attention to quality on what you program into the computer.

You love creating

A writer creates a book by composing letters and words in such a way that produces interesting stories. A writer would use modern tools such as a computer with a great word processor or maybe even an old fashioned typewriter. The tools a book author would use are the means to an end. The creative part is all in the authors head. The art is the intuitive process of creation that is unique to the author. The very same thing can be said for a great programmer. When you start coding, you are composing instructions for the computer to execute. The creative part is on “how” these instructions are executed in such a way that produces software, the end product. How satisfying is it when a customer/user tells you “I love this software”. When a customer tells me that they love my product, it makes my day and this is exactly why I love creating great software. Every programmer wants to be recognized in some form or another for his or her creativity to solve a problem. After all, programmers are problem solvers. We solve problems with our code. Our code is our magic dust that erases issues and makes people happy. How cool is that? How cool is it to start from an idea to something tangible that people can use? Doesn’t every creator want their creativity to be seen, used, and acknowledged? You have the power to change the world with your creativity.

You love problem solving

Programmers are problem solvers. That’s it. I love solving problems with a creative approach. The way you attack problems can be in different ways. It becomes even more interesting when you solve problems that are considered not the norm. You think out of the box. Many times, you do not have to re-invent the wheel because somebody has already solved a problem in the past in some form or another. If that is the case, take a close look how the problem was solved. Would the solution fit on what you are trying to problem? Can you adjust the solution to fit your needs? Can you improve it? Or, can you come up with a unique way to find a solution to a problem? How do you approach the problem? I find solutions to problems in all kinds of places, while taking a shower, while shaving, while starring into the sky, while playing a computer game, etc. When you get ideas to solve a problem, it is one of the super exciting moments when it happens. My point is that your solutions can come anytime. It does not matter if you are sitting in front of the computer or not. You should be open to think and analyze about problems no matter where you are. Give these moments a chance hen they come, explore it further and be open to whatever idea will come to mind.

Stay motivated

You will not be able to create fantastic code if you are not motivated. You have to be motivated and enjoy programming in order to produce some amazing creations. You have to get your juices going. For some, like me, you have to be in the “zone” for some crazy creativity to come out of your noodle. For me, listening to music while programming get’s me into the right mood and kick of some “zone” explorations. So, if you are motivated on one day, how do you stay motivated the next day? One thing I do that has worked for me for many years is that I “carry over” motivation to the next day. The way I do this is as follows: when you work on a particular challenge to solve a programming problem and you eventually find a solution to it, do not implement the entire solution the same day even if you could implement it within minutes. Don’t do the whole implementation. Keep some of the implementation for the next day. When you do this, you can start programming the next day and “re-ignite” that motivation to complete it. What will happen is that you are now on a roll and you will be able to pick up other challenges easier and keep the momentum for that day. This little trick of “carry over” has helped me many times of the years. It unleash some energy the next day even though you may have not felt like it to program at all.

Be willing to learn

A great programmer NEVER stops learning on how to program in different ways even how to program in different languages. Study other peoples code when you have a chance. This will give you an insight of somebody else’s line of thinking to find a solution. This might show you some ideas that you were not thinking about before. Be willing to learn from others, always. Don’t think you know it all. There is no such thing. There will always be somebody else you knows a lot more than you do. So, be willing to learn from anybody. It does not matter if the other programmer is a junior or a senior programmer. Stay open to learn especially “how” they achieved a certain solution.

Learn assembly programming

Yes, you read correctly. Learn how to program in assembly. I know there are tons of high-level languages that you can learn as a programmer such as Java, C#, C, C++, Delphi, etc. However, trust me when I tell you: “You will be a better programmer when you learn how to program in assembly”. You will have an edge over somebody who does not program in assembly. Believe me. What programming in assembly will teach is invaluable compared to any other high level programming language. You will truly appreciate the power of the computer. You will be able to see into the insights of the computer. You will be on a higher level of technical excellence when you know how to program in assembly. I personally love Microsoft’s Macro Assembler (MASM) for Windows over all the other assemblers for many reasons. One reason is simply that Microsoft has pored a huge amount of resources over the past 36 years into MASM. MASM was created in 1981 and no other assembler has received this much attention, ever. Microsoft maintains MASM today. When you learn to have absolute power of the computer and with absolute freedom to create ANYTHING you want with assembly, you will gain a level of insight that is hard to describe. In many ways, assembly is actually easier than many high level languages. It is absolutely fascinating to be able to directly manipulate a CPU register. It is fascinating to change one bit and affect an outcome of an operation. Just fascinating. I could list many other reasons why but I leave it up to you if you want to step up to be a great programmer and learn how to program in assembly. Start creating a simple Windows app in assembly and then feel the power. You won’t regret it.


I hope that the above points will help those who aspire to become great programmers. Stay fresh; stay crazy because you have the power to change the world!

VisualMASM Source on Github

VisualMASM_1_0-MainI decided to release the source code of VisualMASM on Github. VisualMASM is an IDE for Microsoft Macro Assembler (MASM) and makes it a little easier to create Windows and MS-DOS applications in x86 assembly.

The move to release the source code allows me to share the code base for more feedback and also keep the project going with potential project contributors. The source code that I will be adding to Github is not the current code base but a new version of VisualMASM 2.0. I want to make some big changes to VisualMASM and I figured this is a good way to also share the source code at the same time. You can follow along the changes of VisualMASM as I will build it out more over time and when time permits at the Github repository here.


What is a great software design?

I know everyone has their own opinion about what a great software design really is. For me, it’s rather very simple and be summarized in one sentence:

“A great software design can easily be changed in the future.”

In all of my designs, this is my primary goal in any architecture. Be very, very, careful of any library, frameworks, etc. you are thinking about adding. Do not add accidental complexity to your system because it saved you a few lines of code. Do not do it. Keep it simple before you start adding dependencies in your code. You will own this dependency for a long time.

If you are starting a greenfield project, start simple and stay simple until you have no choice and add additional complexity. Resist the temptation of adding this “cool” library or framework.

So, remember, “A great software design can easily be changed in the future.” Stick to your software architecture and stay disciplined and avoid feature-creep in the design. Don’t cut corners and let the team members know that it is important to keep the design simple.

There is enough complexity to deal with because you are creating software. Concentrate on the Ubiquitous Language. Make sure you see that language in your code.

Well, enough rambling, just wanted to write down some thoughts and to remind myself as well.

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.

Microservices by Martin Fowler

In the last 6 months or so, I’ve become a huge fan of Microservices. I love the concept because Microservices are a fantastic extension of domain driven design. One of the core behaviors of Microservices is that no other process is allowed to talk to the data it contains directly (in a database, for example). Any process that needs access to this data, needs to talk to the Microservice. This is exactly what a business entity (aggregate or not) in a domain model is doing. This is what encapsulation in object orientation is all about. To be more specific, a typical domain object has behavior and data, as you know. A domain object will not (and should not) let any other object or process access its data until it passes through its behavior(s). That’s why domain objects (entities) have clearly defined interfaces to talk to.

Now, if you scale this behavior up into components that run in their own processes, these microservices are doing the same thing but from a component point of view: “No other object running in another process is allowed to access another process’s data unless it talks to the behavior of this other component, the other microservice”. This has been my observation and I really have become to like the concept of Microservices. Microservices are a fantastic way of building cloud-based software and with the right PaaS solution, you can create Microservices on premise and simply deploy to a PaaS that also runs on premise or in a public cloud such as Cloud Foundry or AWS, for example.

I’m a huge fan of Martin Fowler. It is not “official” until Martin Fowler has written or spoken about any subject in the Software Industry. Anyway, here is Martin Fowler’s awesome 25 minute explanation of Microservices.

Updated C# Reference Implementation

I have updated my C# reference implementation and included FluentValidation on some of the DTO objects. I also updated the ErrorMap to include validations on the server side as well as on the WPF client side. This version also includes a sample SQL Server Persistence Provider. As always, you can get the latest code on my GitHub repo.