Skip to content

Episode 26 – Rinat Gits Committed

2013 March 27
by Kerry Street

In this episode, there is a lot of new code to dig into. Kerry and Rinat cover the newly added features, discuss how the console relates to future UIs and assists with ongoing maintenance, dabble in Event message design, and get into the CQS pattern that was used to implement some of the Entity classes. They wrap-up with how the current message-based approach can be applied synchronously or asynchronously depending on needs, and explain why there are hints of Redis in the code repository.

Download (mp3): Episode 26 – Rinat Gits Committed – (47 minutes)

Subscribe via RSS | Subscribe for free in iTunes

Episode References:

What do you think?

5 Responses Post a comment
  1. April 3, 2013

    I’m glad to see that you’re still going strong! I’ve finally had some time to catch up on recent episodes.

    I very much agree on putting more information then strictly unnecessary in events. Having enough information to make the event it readable and understandable to a human seems like a good rule of thumb!

    Putting the date in the event however seems to complicate testing quite a bit, but I do see that it might be where it belongs. I’ve hacked on a personal pet projects while reading Vernon’s book and I did notice that putting the event timestamp in the event message header produced some unwanted coupling to the infrastructure.

    • Rinat Abdullin permalink*
      April 4, 2013

      Yes, I agree that including timestamps might complicate testing a bit. However, that’s a tradeoff :)

  2. Kerry Street permalink*
    April 4, 2013

    What is an example of how the timestamp inside the message can complicate testing? I view the timestamp that is inside of every Event message as a fact of what the time was when it happened and not sure I would ever test it for other than its existence maybe. I guess you may want to test that the correct time is being used but I am curious how you guys have found it to complicate testing in the real world.

    @Kim: The way I heard it, it seemed like there would end up being two different timestamps. One in the message header that non-domain infrastructure may or may not care about and domain-specific timestamps inside of the message payload itself that could be used by the domain and not couple it to the infrastructure. Maybe I heard that wrong.

    @Rinat: Do you end up having timestamps in both the message headers and inside the message contract or just one inside of the message itself?

    • April 4, 2013

      Time is just one of those things that always seems to complicate things tremendously.. :-)

      Without the timestamp it’s fairly straight forward to do unit testing without having to expose getters for all the fields in the event (with a proper equals / hash code implementation and given that all the fields in the event are predictable based on the input).

      One might argue that exposing getters on event classes is not only okay, but necessary…

    • April 4, 2013

      But yeah, I really think that the timestamp belongs in the event. It’s just a shame that time have to complicate something that would be so elegant without it :-) C# people already make fun of Java programmers for all the over engineered factories and I don’t want to be the one that introduced something like a AbstractSystemTimeEnterpriseSuperDuperEventTimestampingFactory :-)

Leave a Reply

Note: You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS