A simple update of an object is as complex as adding a new instance of the object, which means it is both straight forward and laden with all kinds of caveats and unlying processes. As with creating a new Patron, it is trivial for me to put together a contrived example of code that will technically satisfy the requirements for “User Can Update a Patron”. A unit Test will create a new Command that will be validated by the Factory and then passed to the MessageQueue for persistance by some other process.
For the fourth year in a row, on Columbus Day weekend, I have completed the Bank of America Chicago Marathon. Previous years have culminated in mixed results, both by the clock and in my own experience. 2013’s marathon was a disaster in both time and how I felt during the race, but provided me with invaluable experience and a drive to do better. By the time the 2014 Chicago Marathon came around, I had taken up speed training with Coach Leach, focussed a little more on my running form, and put together a strong showing at the 2014 F3 Half Marathon. However, during last year’s race, I had set unrealistic expectations, especially while trying to run with a sore back. 2015 was not a good year for me, overall - but I was determined to turn things around for 2016.
For a while, I have been battling with where validation should occur, and who is responsible for ensuring that the information in a command is good data. For the first layer of data validation, I am turning to the Command to validate itself — the mere application of data types is a rudimentary form of data validation, so including addition simple validation extends that basic logic.
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.