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.

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.

Slides for Sacramento .NET User Group

Update 04-05-2015: I completed the SQL Server Provider. Latest code is on GitHub.

I had a lot of fun presenting last night at the Sacramento .NET user group. It was great to hear that people learned a lot and are looking forward in incorporating the things they have learned about the Provider Model design pattern and object persistence in general into their own projects. The slides are available for download here. The source code of the entire reference implementation is available here. I will be finishing up the SQL Server provider within the next few days and make it available in my GitHub repo.

Object Persistence Reference Implementation

I’ve been updating my reference implementation in the last few days. I’m actually using this reference implement in my own projects. You can download the latest version on my GitHub repo.

This is a complete .NET C# reference implementation to help you jump start a service oriented system running in a cloud environment such as Amazon’s EC2 or on-premis clusters.

This reference implementation shows you how to build a client and the server side. The client side is a sample WPF application that communicates via http REST requests using JSON payloads to the service side. Of course, you can use any type of client as long as the client can communicate via http and REST based JSON’s.

The service side is using a Web API 2 service layer that communicates to a central domain model. The service side demonstrates how to handle exceptions and edge cases and how to communicate failure to the client.

The persistence layer demonstrates the extreamly powerful provider pattern to store the domain objects into the following databases:

  1. db4o (an object database)
  2. Redis (a NoSQL database)
  3. SimpleDB (a NoSQL database)
  4. SQL Server (comming soon)

Please note that the entire system has no knowledge on how the objects are stored. All implementation details are in the individual providers listed above. This means that you can switch the persistence provider without having to recompile and therefore switch a running system from one persistence store to another.

I will try to create a sample SQL Server provider soon.

appsworld North America 2015 at Moscone Center West, San Francisco


I’m a confirmed speaker at the appsworld North America 2015 at Moscone Center West, May 12-13 in San Francisco, CA.  Discover the future of multi-platform apps. See all confirmed speakers. This sure will be an exciting event. I’m still working on my presentation that will include Redis, Amazon AWS, C#, and more. I will see you there.