Simplifying Message Handlers

One thing I don't like about the message handler examples I've seen are all the interfaces that you have to implement. For instance:

public class CustomerHandlers : 
    IHandles<ConvertLeadToCustomer>,
    IHandles<CustomerCreditLine>,
    IHandles<CorrectCustomerAddress>
    .... // lots of these
{
    public void Handle(ConvertLeadToCustomer message)
    {
        ...
    }
    
    ... // lots of these also, but they actually do stuff
}

These interfaces help you to match up messages with the handler method and gives you something to cast the handler to in order to call the appropriate method. Ultimately it ends up like this:

    ((IHandles<T>)handler).Handle((T)message);

The first alternative I discovered was to use dynamic. I didn't have to implement all the interfaces, maybe just one interface on the parent class, and let the methods document for themselves the messages they handle. Assuming I know the right method exists on the handler (due to reflection), I can let the DLR figure out how to actually call it:

    ((dynamic)handler).Handle((dynamic)message);

Note that 3 calls to the DLR are actually made. One for the message, one for the handler, and one for the method call. This works, but you run into problems if you are lazy like me and have some event handlers that handle all events. For that I use a shortcut syntax.

public class DatabaseDenormalizer: IHandles<IEvent>
{
    public void Handle(IEvent message)
    {
        // get message's actual type name
        // call a stored procedure with same name (if it exists)
        // using events properties as parameters
    }
}

In that case, dynamic wouldn't work if you had both a generic handler method and a specific one. The generic one would never get called, because the DLR always goes for the most specific call. Also, dynamic has a bit of overhead as compared to the direct method call (but not anywhere near the slowness of a MethodInfo.Invoke() call).

Edit: Correction, MethodInfo.Invoke is only "slow" in simple tests. When the call actually does some work (and is in Release mode), Invoke can be just as fast as a direct method call.

So being the crazy person that I am, I kept looking for an alternative where I could minimally decorate my message handlers, but still have decent performance. I want them to look like this:

public class CustomerHandler : IMessageHandler
{
    public void Handle(ConvertLeadToCustomer message)
    {
        ...
    }

    public void Handle(RequestCustomerCreditLine message)
    {
        ...
    }
}

So after googling around for information many times before, I finally hit the magic combination of words today to bring me to this post from 4 years ago by Jon Skeet. The last code snippet (with some tweaking) pretty much solved my conundrum. It's admittedly pretty complex code, but I'm willing to accept that for improved performance, and easier setup on my objects, plus the complexity is on code that I will likely never touch again.

Asynchronous Programming

I'm always forgetting the link to this resource on multi-threaded programming, so I thought I would post it here. It's really a great resource if you're getting started with multi-threaded programming in .NET or you just want to brush up on the nuances.

http://www.albahari.com/threading/

My Next Software Architecture

I've been thinking more about how to architect my next web-based software project. I'll be honest with you, I'm not a pro at this yet, but I'm trying to figure it out and get some experience. So I'm going to bounce some ideas off of you, Internet, as well as work out some of my thought processes. Here are some choices that I have in mind. Note that these things have been around a while, and I've played with them a little, but it's fairly new to me.

Profile and Strategy

Non-distributed

Pretty much all of the web apps I write manage a business's internal workings and are not distributed (in the large-scale sense), or are at most distributed to a few satellite locations. (This has historically been handled by file replication, database replication, and private networks between locations.) Therefore, I'm not going to add extra trappings that require a lot of configuration or overhead. For example, I won't be using a durable message queue. The core of the system will be running in-memory, and the components will mostly communicate in-memory.

CQRS

Earlier in my career, I thought it was a good idea to directly use business entities for UI views. That ends up leading to your domain objects being bloated with some UI-only concerns and vice versa. The common alternative is to create different view models as projections of your live business entities. But in order to do that, you have to load your business objects and map them to view objects. So this ends up with a lot of mapping code maintenance, and the mappings can get complicated.

The CQRS strategy keeps two sets of data updated; the domain (business) object data, and the view model data. The benefit here is that each can evolve at their own pace without greatly affecting the other. It's also a bit faster because it is no longer necessary to load the domain object first -- you just load the data straight from database to client. The downside is that you have to update 2 (or more) sets of data. But overall, it eases the complexity of trying to use one set of object for 2 distinct purposes.

DDD

My problem domains tend to be, on average, moderately complex because I'm representing internal processes of a business. DDD is meant to address complexity, but it's more about behaviors and communication patterns than code patterns. Probably the one code pattern to take away is to structure the domain objects in the same way and with the same names that customers use to describe their processes. That typically means insulating the domain objects from view and persistence concerns, and let it focus on business. If not doing CQRS also, you end up with the mapping code issue.

Messaging

Using messaging brings additional overhead to the project. (As compared to direct method calls on domain objects.) But it decouples the clients from the domain and generally just bring options to the table. In my case, I'm leaning more towards a completely HTML/Javascript-based UI, so direct method calls into .NET are not an option anyway. I could write MVC actions which are coupled to domain methods, but in that case it's about as much overhead to implement as messaging (just a different kind of overhead), and the coupling still causes ripple effects and interface maintenance.

Specific Tactics/Tech

Event Sourcing

This tactic lets you represent your domain objects in persistent storage as a series of events, which are basically just classes with the appropriate contextual information. Examples: CustomerCreatedEvent, CustomerAddressCorrectedEvent, CustomerCreditLineRequestedEvent, etc. You can imagine all of these events having a customer id. The address event, you can imagine having properties related to address information.

This has a number of advantages including trace-ability, replay-ability, easy and performant persistence story. The main disadvantage I see to this is that some of the messaging concerns (events, specifically) end up leaking into your domain logic. However, anything message-related done by your domain objects is usually very simple (plain assignment statements).

But event sourcing also opens the possibility of using non-relational databases. For me, it is usually the case that the domain deals with relationships, and view models are relatively flat. When the domain is event sourced, the persistence format is flat. This opens up the doors to alternative databases (such as NoSQL) which tend to be faster and easier to work with. Which leads me to my next point...

NoSQL Database

A traditional SQL database provides a lot of capability for reporting. However, it's a real pain to work with for application data. Most of us don't think about it because it's become second nature. Running a basic SQL statement requires you to 1) have a magic string somewhere with the query or stored procedure to run, 2) wrangle objects like SqlDataAdapter, SqlConnection, etc., 3) map parameters into the query, and 4) try to run the query and interpret the results. (For select queries, there's the additional pain of mapping/casting the DataSet back to an object.). This is painful enough that most of us create abstractions around this process. The first evolution is a DAL that maps method calls to SQL statements. Later evolutions end up being a repository and/or ORM. An ORM requires that you stay abreast of the ORM-specific extensions and code around its design. A repository (or even a simple DAL) requires manual coding and maintenance. In the end, no matter what you do, dealing with SQL is a lot of work. Contrast that to the potential ease of using NoSQL databases, which could take your object as-is and store it straight to the database (e.g. db.Store(message);). That's with no custom-built abstractions, no magic string SQL statements, and no extra ORM framework to learn. That's one compelling persistence story. Even if you need a SQL database for reporting, this can just be an additional integration point as though it were another read model to update (from the CQRS story). :)

Additionally, some NoSQL databases have REST APIs, which means I wouldn't even have to implement a read-layer for the HTML5 UI. The only part that bothers me about the REST API is security. And I haven't yet researched my options there.

WebSockets
The websockets feature is one of the most exciting web technologies to come out in a while. It allows the server and client (e.g. browser) to push messages to each other in a low-impact way. Previously, I wasn't using any external bus (e.g. MSMQ), because the overhead and administration needed to use it wasn't worth it. But websockets are rather simple to get running and are still a developer concern (as opposed to an administrative concern like MSMQ). I want to use websocket connections to serve as my program's contact with the outside world. It's not a durable bus, but since my program is in-memory and not distributed, that really doesn't matter.

One other interesting point is that web sockets provide better asynchronous capabilities. If I send an AJAX request from JavaScript, to an MVC Action, both the AJAX request (on a separate browser thread) and the MVC Action are kept open and waiting until the program finishes the action. Using websockets, I have the capability to take the command, hand it off to a queue, then have a callback send a message back to that client notifying them of completion. I can also have an event websocket to allow external listeners.

The downside to WebSockets is the feature is not widely supported currently. To host WebSockets natively in IIS, you currently have to have Windows 8 or Windows 2012 Server. As far as clients, WebSockets is not supported on most browser versions aside from the current crop.

HTML5/Javascript UI w/ MVVM
HTML5/Javascript is pretty much the direction that the web has taken. I ruled out both WebForms and MVC (the design, not the project type) for the UI due to both performance and knowledge dependencies. Both approaches (traditionally) post back to the server, let the server make some UI decisions, and then send the decision (or command) on to the business layer (or domain). It's basically an extra hop (to use a network term) as compared to a purely in-browser UI. And as we all know, external communication is often the most expensive part of a given operation.

But performance alone is not enough, and in fact using a solely HTML5/Javascript UI is only possible due to some nice Javascript frameworks. My personal choice in the matter is jQuery and Kendo UI (which has controls, MVVM, data sources, etc.). With MVVM, you can completely separate the view from the model, which makes working with the code a lot easier. I end up with the following for each view: view (.html), style (.css), view helper (.js, for any extra control-related functions the view might need), and view model (.js). Then for more complex scenarios, I add more view models and/or script files which listen for view model changes and react accordingly. It's all pretty fast.

This style of development does take some getting-used-to compared to server-side UI development. But one of the reasons I like Kendo UI is because there are a lot of functions that are pre-integrated as compared to taking separate libraries for UI controls, MVVM, validation, etc. and trying to integrate them together.

Getting .NET 4.5 WebSockets Working

I just spent most of the afternoon trying to get WebSockets working with Visual Studio 2012 and an MVC project. Most of the examples seem outdated (from old RC builds) or too low level, and the few updated ones weren't complete. So, here's my little guide on how to get started with a simple echo/chat program. It just takes 2 classes and a test page.

NOTE: WebSockets on IIS only works on Windows 8. Windows 7 does not have the necessary websocket DLL that is needed by IIS. :( That wrinkle aside, WebSockets will work with IIS 8 Regular or Express editions. This demo used IIS Express.

First, you must create a new Web API project. In this example, the project is named (with great flare and creativity) "Project1". Then, you need to add the Microsoft.WebSockets package from NuGet. (Right-click the project, click Manage NuGet Packages..., search field in upper right: microsoft.websockets, select the Microsoft.WebSockets package and click Install)

First create your WebSocket Service class, and put it somewhere in the project (mine is in /Controllers):

using Microsoft.Web.WebSockets;

using System;

namespace Project1.Controllers

{

    public class ChatClient : WebSocketHandler

    {

        public readonly Guid ConnectionId = Guid.NewGuid();

        private static WebSocketCollection chatClients =

            new WebSocketCollection();

        public override void OnOpen()

        {

            chatClients.Add(this);

            chatClients.Broadcast(

                "Client joined: " + ConnectionId.ToString()

            );

        }

        public override void OnClose()

        {

            chatClients.Broadcast(

                "Client left: " + ConnectionId.ToString()

            );

            chatClients.Remove(this);

        }

        public override void OnMessage(string message)

        {

            chatClients.Broadcast(

                ConnectionId.ToString() + " said: " + message

            );

        }

    }

}

Note I'm using Guid as a connection id, and the messages end up looking pretty ugly: 0195093f-70a5-4bfe-b707-8ac96ba94c31 said: test. But you can change that for your own needs.

The next step is to setup an ApiController. This is necessary to upgrade the HTTP request to a WebSocket request.

using Microsoft.Web.WebSockets;

using System.Net;

using System.Net.Http;

using System.Web;

using System.Web.Http;

namespace Project1.Controllers

{

    public class WebSocketController : ApiController

    {

        public HttpResponseMessage Get()

        {

            HttpContext.Current.AcceptWebSocketRequest(

                new ChatClient()

            );

            return new HttpResponseMessage(

                HttpStatusCode.SwitchingProtocols

            );

        }

    }

}

As noted in another example I found, the first using statement is VERY IMPORTANT. It adds the AcceptWebSocketRequest overload that is needed for this code. The other overloads are lower level than I wanted.

That's it! But wait you say, how can I test it? Ok, here ya go. This is a simple html page I created to test the application. It doesn't use any external files (not even jQuery). You can replace the contents of Views/Home/Index.cshtml in the project with this:

@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Index</title>
    <script type="text/javascript">
        var connectButton,
            disconnectButton,
            messageInput,
            sendButton,
            responseDiv,
            uriSpan,
            uri,
            webSocket;

        var connect = function () {
            connectButton.disabled = true;
            disconnectButton.disabled = false;
            sendButton.disabled = false;
            webSocket = new WebSocket(uri);
            webSocket.onmessage = function (e) {
                responseDiv.innerHTML +=
                    '<div>' + e.data + '</div>';
            };
            webSocket.onopen = function (e) {
                responseDiv.innerHTML +=
                    '<div>Connecting...</div>';
            };
            webSocket.onclose = function (e) {
                responseDiv.innerHTML +=
                    '<div>Disconnected.</div>';
            };
            webSocket.onerror = function (e) {
                responseDiv.innerHTML += '<div>Error</div>'
            };
        };

        var disconnect = function () {
            connectButton.disabled = false;
            disconnectButton.disabled = true;
            sendButton.disabled = true;
            webSocket.close();
        };

        var sendMessage = function () {
            var message = messageInput.value;
            webSocket.send(message);
            messageInput.value = '';
        };

        var setup = function () {
            connectButton = document.getElementById('connect');
            disconnectButton =
                document.getElementById('disconnect');
            messageInput = document.getElementById('message');
            responseDiv = document.getElementById('responseLog');
            sendButton = document.getElementById('sendMessage');
            uriSpan = document.getElementById('uri');
            uri = 'ws://localhost:52618/api/websocket';
            uriSpan.innerHTML = uri;
        };
    </script>
</head>
<body onload="setup()" style="font-family: sans-serif;">
    <div>
        <div>
            <span id="uri"></span>
            <button id="connect" onclick="connect()">
                Connect
            </button>
            <button id="disconnect"
                disabled="disabled"
                onclick="disconnect()">Disconnect</button>
        </div>
        <label for="message">Message</label>
        <input id="message"/>
        <button id="sendMessage"
            onclick="sendMessage()"
            disabled="disabled">Send</button>
        <hr />
        <label for="responseLog">Response</label>
        <div id="responseLog"
            style="border: 1px solid grey;
                   width: 600px; height: 400px;
                   overflow: auto;
                   font-family: monospace;">
        </div>
    </div>
</body>
</html>

NOTE: Change the uri value to match the port your project uses. Otherwise it should work as is.

And here was my test run in Chrome 21 and IE 10.

Choosing a Database

Choosing databases used to be pretty straightforward. The answer was always a SQL-based relational database. Nowadays the landscape is different.

I decided to use a non-relational database (referred to as NoSQL) for my next project. Why? Because I don't need it. The plan is to use denormalized read models to service UI views and use event sourcing for my domain objects. Neither of these things require relations at the database level. Further, with the use of a document database, I could even nest some relationship data that might be required for the view.

So which document database to choose? Firstly, my project will use HTML/JavaScript as my main UI, so a REST API into the database will save a lot of code. A document DB with a REST API pretty much narrows it down to CouchDB or RavenDB. What follows is my decision process for choosing between them for a .NET web-based application.

Note: Please correct me if you see any incorrect information!

Licensing

-CouchDB is free and uses the Apache 2.0 license, which is not all that restrictive and can be used in commercial software.

-Raven is dual-licensed with the AGPL (which is the nastiest viral license out there) or a commercial license (which you pay for).

Being as my next project has no guaranteed revenue but I wanted to retain the rights to sell it commercially, paying for a database wasn't ideal when a free alternative exists, and I almost settled on Couch right here.

Note that Raven's AGPL license has an added exception that allows you to use a different OSI-approved open source license for your project that uses Raven and not have to convert to AGPL. But it doesn't free the users of your project from the AGPL's constraints.

Clients

I need a .NET client, primarily so the server can update read models.

-Raven has a built-in .NET client with support for LINQ queries, performing updates, and defining indexes in a .NET language. (And a lot more things that I put in the Developer Capabilities section.)

-CouchDB has only the REST API. There are many user-contributed libraries to wrapper the REST API, but none have the depth and capability of Raven's client. Non-trivial database instructions (like updates) must be written in Javascript, which is a bit awkward from a .NET language.

-Both databases have Web-based administration tools.

Developer Capabilities

-RavenDB as lots of advanced options: loading related documents (almost like a relational database), full-text queries, partial updates, set-based deletes and updates, transactions, spatial queries, ... the list goes on.

-CouchDB has more capability as an application server with design documents, validation-, and show-functions. But I don't need this, and I don't like this mix of concerns. Also, CouchDB is missing an important capability for my project; partial updates.

Deployment Stories

-RavenDB can be run as easily as referencing the DLL in my project and newing up the store (embedded mode), or can run as a Windows service, or an IIS application. RavenDB server is tied to the Windows platform (although the client can run on most anything through Mono). This would be a downside for some, but this is the platform I'm targeting.

-CouchDB is supported across many platforms, but it has basically one deployment story: run as a service (or daemon), with or without console interaction.

Distributed Stories

-RavenDB has replication and sharding support. Sharding is decided on the client, though.

-CouchDB has replication, load balancing, and clustering. The latter two are more for data-center scenarios, whereas Raven's sharding is capable of dealing with data locality (by geographic region, for instance) in addition to just hashing by key for data-center scenarios. Although, load-balancing and clustering are decided on by the server.

Conclusions

Based on my deciding factors, RavenDB is clearly the winner. Targeting the .NET platform, RavenDB brings much more capability to bear than CouchDB. It is also much easier to integrate with .NET code. Sharding support brings better scalability than replication for geographically distributed applications. The only downside is there is a cost for commercial use. However, that cost is well justified considering what it brings to the table, and the amount of integration time it saves with .NET. It's also still available for free to open source projects.

IE8 Javascript Performance

Today I was faced with this little peach of a problem in IE8. Horrid performance, as demonstrated by the following IE8 Javascript Profiler shot.

There weren't any noticeable performance problems in IE9 or Chrome, so I figured this was just IE8's slow-boat Javascript performance. I started looking around for problems with jQuery.removeClass() in IE8, but didn't find that much.

Upon further examination, the problem was actually a couple of unintentionally recursive calls. I am using Kendo UI MVVM, using one view model for the entire page, but I also have some fields whose members are calculated by script when the model changes. (I have my reasons!) So, whenever those properties would get updated, the change event on the view model would fire, and the properties would get calculated again, which would then trigger a change event, etc. Since the code was doing deltas on the calculated object, eventually no changes would be made, and the recursion would end. Further testing revealed that the code was getting recursively called about 75 times and 7 seconds too many.

My first thought to fixing this was place conditionals on the change event:

viewModel.bind("change", function(e) {
    if (e.field != "someProperty" && ...) {
        // recalculate
    }
});

But I realized that future-me is unhappy with this solution. This would be a pain to (remember to) update when I added features to this page. So instead, I split the view models. There's one for user-updated fields, and another for manually calculated fields. The calculated fields trigger a recalculate only when the user-updated view model is changed. This nicely got me back down to acceptable performance.

IE8 apparently still hates removeClass, but it's a lot better than before. Note that the same (fixed) code in IE9 runs all removeClass calls combined in 1ms, and the biggest hog only takes 28ms, and the next-largest is 9ms.

Morals of the story:

• Users should stop using IE (a moral of every web dev story)
• I should to sanity check JavaScripts with a profiler.

CQRS - Lessons Learned

So I'm thinking about what I might do differently next time I write an enterprise web app of sufficient complexity. The CQRS principle is great, and provides a lot of clarity to the problems created by using domain objects for both reads and writes. However, many of the presented examples have extra architectural trappings that were not needed in my case: especially a message bus.

Here's what I think my next one might look like.

Javascript-based MVVM UI

No one reads my blog, but if you had, this seems contradictory to previous posts and the fact that I hate JavaScript. But hating JavaScript as a web developer proves about as useful as hating air as a human. I pretty much have to have it, so why not make my experience with it as positive as possible. I ultimately really enjoyed my JS-MVVM experiences, despite being out of my comfort zone (without Intellisense or type checking). The performance of the application was amazing.

My flavor of JS-MVVM was Kendo UI for the last project. It's still a relatively new framework, but it's fairly well-rounded for its age. It's biggest strength to me is that it's only one product for UI controls, MVVM, validation, etc. That's as opposed to integrating several products for the same purpose like Knockout.js, jQuery UI, Chosen, etc. Now what it has in breadth, it lacks in depth. The controls are great, but not as customizable as I would like in many cases. Documentation is lacking, but so far it has at least had enough hints to get me pointed in the right direction.

Messaging

I have really liked the clean separation that messages provide. Particularly, I like commands and events. They break up user intent and domain activity into bite-sized chunks. This has helped guide me to focus on, analyze, and encapsulate the business value of a feature, more than just it's technical requirements. These chunks are much easier to understand, and react to than in a traditional data-centric model where a lot of interpretation code (based on what fields on the record have changed) has to take place before you can get into the business value.

Partial Synchronicity

In my last implementation, command executions were synchronous up until events were published, then the integrations (event handlers) ran asynchronously. If any domain errors were generated during command execution, the dispatcher would catch them and return the exception message to the client. (Bear in mind these are domain exceptions like "An item cannot be it's own parent, except in sci-fi.") If there were no errors, the dispatcher returned success.

I will likely do the same thing next time. I really like being able to give the user immediate feedback about their actions. A lot of CQRS literature espouses asynchronous commands, but I find it is much better to give the user immediate results of a command where possible. So I take this approach first, and I will adjust if I run into scenarios where immediate results aren't feasible.

MVC Actions as Command Handlers

In the last project, I used a separate Command Handler project, consisting of simple objects with Handles() methods for the commands they handled. The UI would post the command to an MVC action, which would then call a dispatcher to find the handler and give it the command to handle.

Next time, I will instead try to setup MVC controller actions as my command handlers and cut out the dispatcher part. This would allow me to eliminate two bits of reflection code; a custom model binder, and a command dispatcher (router). The dispatcher does do a few things for me; logging the command, executing the validate routine, returning something to the client on error. But I can implement an abstract controller class to do those things.

I'm not entirely sure I will be able to make this work. I'm hoping I will be able to use the ActionSelectionAttribute to use overloaded methods as actions. Otherwise, each command will need a distinct URL that I will have to keep track of and give to the client; then all I've done is moved the command routing code up a level. (Not desirable.)

Update: Upon further reflection, I think this is a bad route to go as it mixes concerns between UI infrastructure and command handlers. I think I will keep doing what I was doing, but use the open command messages mentioned below so I don't have to instantiate them and set their properties with my custom reflection code. Instead, I can just call the default model binder to create the class after I figure out what it is from the type hint in the POST data.

If I did go this route, my command messages would have to be open objects (have default constructors and public setters) for the default model binder to be able to construct them. Currently, I am using reflection to get around the private setters, so I'm essentially using them as though they were open objects (with much reflection pain). But once they get in my architecture, they are immutable. But I'm not sure how much benefit this ends up being since their entire life span would be 1) being constructed in the model binder, and 2) have it's data used by the command handler. Private setters would keep the command handler code from changing anything, but ostensibly the command handler's only purpose is to use data from the command object to call a domain method. So, I'm still inclined to give open command messages a try next time.

Provide a JavaScript Command Library to Clients

Currently, I take the .NET commands, convert them to JavaScript, add a type-hint attribute, and provide them in a library to client apps. I don't like having to do this, but I really don't see away around it, since JavaScript is a loosely-typed language. I need some way of identifying the command that the UI is trying to send. Attributes alone are not enough, since two commands could have the same attributes, but trigger different business actions (e.g. DisableUser vs DeleteUser). I feel like this area is one that could still use some further exploration, because that's not really code that I want to maintain.

Event Integration

How to route events (integration) is another area that needs more exploration. What I did previous works rather well, but I feel that it could be streamlined a bit.

Again, I did not use a message bus, since I didn't foresee a need for external integrators. I put all the integration handlers in the same assembly (but different namespaces / folders), so I could use reflection to find them all and be able to route events to them.

Next time, I think I will have each integrator manually registered with the event publisher. The number of integrators is typically low, so the code maintenance would be negligible, and much clearer than a reflection-based solution. Then in the event publisher, when an event comes in, I can use a simple "is" check (e.g. if (integrator is IHandles)) to see if the integrator handles an event before trying to invoke the handler.

If I do need to provide an event stream to external integrators one day, I will have to break down and use a message bus. (I'd be leaning towards MassTransit / MSMQ in that case.) I might keep my current way of doing things, and then add a separate internal integrator which just repeats the message out to a message bus for outsiders. That way I could also control which messages are allowed out.

Possibly Sans Event Store

My last application was a brownfield scenario with an existing RDBMS, so I couldn't start with an event store. I can't get there until I migrate all of the business functionality into the new architecture. I'm not storing events, so I can't load from them. Since I am using events to drive integration, and I did want the load-from-event-store capability in the future, I setup the aggregates to take an array of events in the constructor as though there were an event store. Then, when the repository loads the aggregate, it reads the data from the database (which only has current state, and not the events) and makes a massive CreatedForLoad event to pass to the aggregate, which initializes all of the aggregate's properties from the event when applied. (As opposed to replaying many smaller, actual events that occurred to get the current state.)

I have mixed feelings on an event store going forward. I already want to use messaging and events, and the idea of an event store is absolutely grand. But what's currently out there to provide and support an event store is sorely lacking.

The main event store offering out there is Jonathan Oliver's EventStore. It is a great piece of software (and happens to be free / open source), but it lacks all but the most basic documentation (last I checked). I really didn't find it at all intuitive to setup. I did manage to get it working, but I felt that my knowledge of operating it was far too inadequate for the level of trust I wanted in a piece so integral to the application.

Supposedly there will be an event store offering from Greg Young next month, but I can't really say it will help the situation without seeing it. I guess we'll see.

The other problem with event sourcing is visualization of data. How do I look at information from the event store to triage/verify production issues? How do I achieve the advertised "going back in time" to previous states? There's no Management Studio for event stores (to my knowledge). At this point, you have to develop your own toolkit for this purpose. Therefore, these features have a non-trivial cost.

So the jury's still out on this one. I want to try it with a new app, but I have reservations.

UPDATE: Most of the stricken text above was based on impressions formed when I implemented CQRS+Messaging+ES for the first time in spike code, when it was too new to me to really grok. After implementing such an architecture, I can see that it fits in right where it should, and the config makes more sense. I will definitely use an event store next time.

Read Layer

I really don't have anything innovative on this front. I have an MVC action that basically executes a query to get a DataSet. It then converts the DataSet into a Dictionary and then serializes that with the built-in JavascriptSerializer and returns it as JSON to clients. (That way has the least hops to get from DataSet to JSON that I found.)

I don't anticipate this changing in a new application. Using some naming conventions, it's very quick to add new reads. The most time consuming part is developing a query. In a new application, I will probably have tables for each read model, so even that should be quick too.

That's all I can think of for now.

CQRS Experiences So Far

So, I'm always looking for new tech, methodologies, anything that can help me do things better. The latest approach I've gone for is CQRS; that is Command-Query Responsibility Segregation.

The first hurdle is in figuring out exactly what CQRS is. As defined, it's pretty simple. Commands are on one object, Queries are on another. However, much of the information out there is inter-mixed with a lot of other architectural concepts and strategies that fit well with CQRS, like messaging and event sourcing. It gets pretty tough to see the big picture with so many concept details in the mix.

Eventually, I settled (perhaps wrongly) on a CQRS/ES/Messaging architecture for an enterprise web app. I say wrongly because the app is already very data-centric, and the users are accustomed to it being that way. However, the data-centric nature of the app had some major drawbacks, such as inscrutable business logic code, business logic being pushed to the UI (due to complex inter-relations and validation between fields on the record), and so forth.

The first hurdle I ran into was how to communicate commands and events. For this web app, a typical message bus (MSMQ or RabbitMQ) wasn't needed, at least not for now. Not only that, but this app is already a configuration nightmare that I didn't need to complicate further. I experimented with receiving commands through WCF (which I abandoned due to the difficulty of calling from Javascript), then .NET 4.5 Web API (which I abandoned because it's in beta and I ran into technical problems with it).

For commands, I settled on using vanilla MVC 3 controllers with a custom Model Binder to convert POST content to .NET command objects. (Custom because the MVC action argument is an interface, and the commands have neither a default constructor nor public setters. So the only way to instantiate the object is through reflection.) On the other side of the coin, I wrote a converter to turn all the .NET commands into Javascript objects so they were available in a Javascript library to the client and also had conversion hints (like the type's .NET full name). The library also includes some basic shortcut methods to execute commands, so the client doesn't manually call $.ajax(...). Instead, they call Command.Execute(myCommand) or Command.Validate(myCommand). I tried to use T4 to generate the library from the .NET command objects, but found it to be inadequate (due to locking the dll among other things). Instead, I have a separate controller which generates and returns the Javascript library when called. All this sounds complicated, but it actually wasn't that time consuming to develop. The time consuming part was researching and evaluating WCF, Web API, T4 before abandoning them.

For events, I also didn't need a message bus for now. Instead, I settled on an in-memory bus of sorts. Instead of the event handler applications subscribing to the event bus, I have an event publisher object that searches for event handlers using reflection (much the same way that my command dispatcher searches for command handlers), and adds their actions to the thread pool when an event is received.

I can't do full event sourcing just yet with this application since it has an existing database that is currently in use, and I'm not able to take 3 years to do a complete re-work. Instead, I have to integrate the new stuff while retaining the existing functionality of what hasn't yet been replaced. What I did do was in my domain repository, I convert the database information (in DataRow format) into an big Created event so that my domain objects don't have any special "load" code paths. The constructor just takes events as arguments to replay them. Hopefully that will make moving to full event sourcing seamless on the domain side.

The read model is also implemented as an MVC controller with get actions for each read model. I tried to do a WCF data service (odata), but our database was just too non-standard to generate an Entity Data Model without a lot of manual XML manipulation. And if I'm going to have to manually generate the data classes anyway, I didn't see the point of being constrained to whatever WCF data service requires / provides.

The UI has it's own ecosystem, since it uses HTML5 / Javascript and MVVM. But basically, it's job is to take the user's choices and make a command out of it. The UI uses various read models to guide the user's choices (e.g. to populate a drop-down list).

So here is an end-to-end look at what happens in this system.

• The UI calls various read models and ultimately generates a command and sends it to the command API (via a jQuery $.ajax POST with the Javascript command object as the 'data' parameter).
• The command API constructs the .NET command object from the POST data (using a custom model binder), then sends the command to the dispatcher.
• The dispatcher looks up the handler for the given command and then calls it with the command
• Note, the command also has a validate method which is called before the command handler is exercised. If the validate method returns an error, execution halts and the validation error it is passed back to the client. Otherwise command execution proceeds.
• Note, domain exceptions are captured here and returned to the client as command errors with the domain exception message.
• The command handler loads the necessary domain aggregate and calls the appropriate method(s) on the it.
• The aggregate performs business logic and (perhaps) generates events.
• The command handler polls the aggregate for events and then passes those events to the event dispatcher. (No event store to pass them to yet.)
• The event dispatcher looks up the handlers for those events and puts them on the thread pool to run.
• At this point, command execution returns to the client as successful since there were no domain exceptions along the way.
• Example event handlers execution process:
• Database
• The database event handler runs. It handles ALL events. It looks for a SQL embedded resource file that matches the event name. If no resource file is found, the event is ignored.
• If a matching resource is found, it's contents are loaded as the query string.
• The event's properties are extracted as name/value pairs and used as parameters to the query.
• The query is executed.
• Note: In this way, the only thing necessary to add a database integration for new event is to add an new .sql embedded resource file to the solution with the event's name. The .sql file contains the query to run when the event is handled.

So, as you may notice, my commands are NOT asynchronous, fire and forget, or even queued. They return back to the UI either Success or Error with Message. My architectural choice was to be able to immediately get the command result back to the user with domain errors. This design lacks presently concurrency handling, but the existing system also lacks this and doesn't suffer much for it. Once a command executes successfully, the event handlers do operate asynchronously. At first I was concerned that the database writes wouldn't happen fast enough to display to the user on the next page hit, but this turned out not to be a problem so far.

So a couple of properties I have noted about this design. My first observation is that there are a lot of steps to add a feature (not even counting tests).

• Generate the command and event
• Add what's necessary to the read model to support the UI
• (maybe) create queries
• (maybe) add to read model
• Add what's necessary to the UI to generate the command
• Views
• Models
• UI Logic
• Add the aggregate method for the domain logic
• Add any needed value or entity objects
• Extend repositories as needed
• Add the aggregate Apply method for the event
• Add the command handler method
• Add the event handler methods / resources for all the integration pieces

"A lot of steps" seems like a pure disadvantage, but the disconnectedness of each program area means that multiple people truly can work on the same feature independently. For a lone developer doing features in a vertical slice, this design seems like a lot of ceremony and context switching. But for a team, I think it chops up the work in a horizontal fashion rather cleanly. The separation points seem to be around commands, events, and the read model. 

Since I am the lone developer on this for the moment, I've found that this design breaks most tasks up to the point where they are somewhat boring, and I end up copying and pasting a lot (especially with regard to commands and events). That could just be the subject matter, though. The interesting parts for me have been in the development of the architecture. The domain holds some challenge at times, but mainly the challenge there is in defining what is needed for the workflow. Sagas can be pretty interesting.

Performance is pretty good in my estimation. With a debug build, I am able to get about 1000 ops/s. Were I to batch operations on the same aggregate instead of loading it from the database for each command, that would probably improve. But at the moment I don't see a need to do that.

MMO Structures That Need to Go Away Pt 1

Servers
The concept of servers (a.k.a. shards or realms) is an antiquated concept that hearkens back to the first days of MMOs when they figured out that 1 server could not handle every player at once.

Servers are a dividing point between players. They create issues of population problems (perceived and real) and server transfers. Having everyone unified together only creates issues for the game designer, not for the player. Some issues that come to mind: Name collisions and Auction House performance or segregation.


One game that has done this server-less concept more or less successfully over the years is Eve Online. In Eve Online, each "zone" (solar system in Eve, planet in SWTOR, zone in other games) is a server, so when you change zones, you are switching servers, and every player currently in that zone is on the same server. Auction Houses are divided across regions so that it's not one massive AH, and to provide opportunities of buying low and selling high across regions. Names in Eve can have 2 names (e.g. "John Smith"), which provides a larger variety than a single-name system. However, zone overpopulation is a real problem and bogs down performance in Eve (e.g. Jita on a Sunday afternoon).


This works pretty well for the type of game that Eve is, but the implementation could be different for other games. In SWTOR for example, each server could house all the planets in one instance. So, Instance 1 of Carrick Station is on the same server as Instance 1 of Coruscant. The difference being that players could change instances on the fly like we currently can when we are grouped with other players in different instances. Several instances could then be in a "collection", which would share the same GTN (auction house) and general chat channels. That would avoid a game-wide, super-massive, slow-performing auction house or chat, while also providing entrepreneurs with some gameplay options. When you log into the game each time, the game could check your friends and guild lists and place you in the same instance with them (or at least the same collection). Collections could also be dynamic in that they automatically scale up or down based on how many people are playing at that moment, so that the zones never appear too sparsely populated. In this type of model, the servers are not tied to your character. I believe this type of model could be more easily migrated to by games which are currently using a typical server model. Name collision could be handled by a random 4-digit code like we've seen with Real ID, Steam, and others. You could still send tells without the 4-digit code if the person you are sending to's name was unique to inside your guild list, friend's list, instance, collection, or just online people. Or perhaps you could send a tell to [Name] [Legacy Name]. In other words, alternatives exist to mitigate name collision. I know I really hate it when my name is taken, and it often is.