User Cannot* Create Patron That Fails Validation**

Vigil Journey

Creating a patron (by which I mean, issuing a command such that some process somewhere will instantiate an actual Patron entity, and perhaps persist it in some useful manor) is all well and good, until someone tries to stuff in data that isn’t valid. Users like to do things like this all the time, so I am going to attempt to protect against it from the beginning. Additionally, by setting up the mechanisms to test validation and perform validation, I should be able to keep a culture of enforcing these conventions throughout development.

A Word On Factory Results and Contracts

Vigil Journey

For simplicity, the PatronFactory’s CreatePatron method just returned an IKeyIdentity. This was a simple interface that requires an Id of type Guid. When the creation method was always assumed to work correctly, this was fine - I don’t have to worry about validation checking, data errors, or anything that might cause a failure. However, in the real world, I need to be aware of these things. As such, the first refactor that I’m going to perform is to change the return type to a multi-purpose class.

User* Can Create** New Patron***

Vigil Journey

The first thing that I learned with Dependency Injection is that it encourages a mindset of “I’ll figure that out that later.” This allows me to put in the bare minimum for what might pass a test, even though I know it will have all kinds of complex integration somewhere down the line. To start this little experiment, I am going to put together a tiny amount of arguably functional code. I will start with the very simple definition of what a User is, what it means to Create an entity, and how a Patron is represented.

Everything Gets an Id

Vigil Journey

There can be a lot of issues with figuring out how to identify an object, especially as I try to track it across various services, platforms, persistance strategies, and even entire systems. For a while, I played around with just having every object contain its own identification field. However, it was painful having to remember to put the same and correct field(s) on every entity. I stumbled upon a blog post (which I cannot find anymore), which talked about pulling the key out into its own class, and have everything inherit from there. I’m not entirely sure I like the idea of a super-base-class, but I think it at least gives me a good place to isolate the key into a globally consistent way.

Stumbling Into Design Patterns

Rovani in C♯

As I have been working on the Vigil project, I have been accidentally stumbling onto various patterns. I will go in search of a way to solve some particular problem, and end up losing several hours while I research some reference the author made about a concept (or, usually, an acronym) at the end of a post as some kind of a posteriori. The two largest design patterns that I am most excited about are Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES).

Hello World!

I am working on migrating my blog from the old hosted Wordpress site that I was using to be hosted by GitHub pages, powered by Jekyll.