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.
For simplicity, the
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.
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.
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.
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).
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.
Why, you might ask. Because I can.
Also, because I want to use my domain to host this, and I think that I can do that with Google Domains and this site. We’ll see how that works out.
The Dopy Challenge is a four day event at Walt Disney World Resorts.
- Thursday - Pluto’s 5k
- Friday - Minnie’s 10k
- Saturday - Donald Duck’s Half Marathon
- Sunday - Mickey Mouse’s Marathon
In completing the Half Marathon and full Marathon, Dopey Challenge participants also satisfy the requirements for the Goofy’s Race and a Half Challenge. This results in six medals, six t-shirts, and four extremely early mornings. I had a lot of fun doing the events, but once is certainly enough for me. It was a unique tour of the parks, getting to run through two for the half marathon and all four for the full marathon; however, circling Epcot two additional times for the 5k and 10k made the final return trip at the end of the marathon torturous. Getting up at 3:45 for four mornings in a row put a huge damper on enjoying the rest of the trip. Combine that with the overall cost, and I cannot see myself doing the challenge again; however, I would consider doing the Goofy Challenge, again.