being in tech

From the last post, I decided to to rename my Aggregate to Individual to align more with a ubiquitous language, a key component of DDD. 😉 I also updated the read model to contain a list of multiple batch statistics so the api would return a single object and not an array of objects.

One of the benefits with TDD is being able to design the ideal interface for an application>

This was the first test I wrote, and it resulted in a hardcoded class to satisfy the current requirements. I also renamed a few things because names are important. Red, Green, Refactor, I’ve now moved this to its own class library and added a reference to it from the tests.

At this point, i have the following list of tests that i have come up with so far:

✅When interest is registered, there should be 1 entry in the read model with a count of one 
⏹️When an interest is registered for a specific year, the statistics should reflect that
⏹️an email cannot be registered more than once

The email check sounds like the easier check to at this point

It’s at this point that I can’t really get tests to pass with hard coded values, at least not for the command handler.

After this simple implementation, I would need to have an implementation of IRepository in order to run the test.

I find that while it might be more tedious to create fakes vs using a library like Moq, I like using fakes since you pass real objects to your services. This means, you don’t need to re-mock things if you ever decide to change the implementation in the future. Having to re-write tests when you are doing a refactoring is defeating the purpose of having the tests.

For now, I’ve created a simple fake for what’s currently required.

Running the test now passes all cases where the command is sent in twice.

Going back to the first test I hard coded, I decided to update it in order to get a real implementation going.

Again, as with TDD, I need the simplest solution to get my tests to pass. So I have a private variable that stores the current read model and every time the command successfully finishes persisting an individual, I update the read model with the latest data so that it is ready to be retrieved by the get.

We now have all the tests green, now we refactor.

Obviously I will want to persist my read model so that it doesn’t reset the next time my app restarts. I’ve refactored the application and created a fakeBatchStatistics repository using the same Fake class I used for individuals and then just calculate the total before I return the response to the query.

I did have to make an update to the fake repository since it is in memory, i didn’t have to worry about saving changes to existing items, but i did need to not add the same entity if it is already in the list.

Logic wise, I think we have implemented most of it. With the latest code, it even covers the 3rd test on the list.

The application logic seems to cover all that is needed, however, looking at our class now, it’s looking a little bit too busy.

Next post will be writing more tests that will focus on using events driving the behavior change in our Domain model. Maybe we’ll finally get to see some event sourcing in action.

Initial repository is here: https://github.com/jocelynenglund/RegisTracker/tree/InitialTests.