Answer To ‘How Would You Design This System?’

Yesterday I asked you to help design a notification system composed of a converter and a high-level business logic workflow, a use case class. The question I left you with was about whether the converter should map to strongly-typed subclasses, or not. If you didn’t read yesterday’s system design article, you can find it here. 

Thank you to everyone who sent in their answers.

I like Steve Buys answer so much I am just going to reproduce it verbatim:

“In my opinion, the Converter doesn’t need to know, or care what types of events the Notifier is going to be notifying about. We may want the Converter to be used in front of other business logic layers in the future which has nothing to do with notifications. Also, every time there is a new notification type, we are going to have to update code in the Converter, and in the Notifier to accommodate this. Doesn’t seem to isolate the changes very effectively.

On the other hand, the Notifier is probably going to need to change anyway for any new type of notification. Making the notification code do the conversion to ChangedStatus option makes much more sense. Especially if, as you said, the Notification message can have different content. This would mean that the CustomerOrderEvent must be able to cater for all of the different types of content, and could have unused fields after conversion if you convert to the subtypes in the Converter. This is not desirable.

I could probably think of a few more reasons to have the Converter return the generic CustomerOrderEvent, but I think these suffice :)”

Steve hit the nail on the head—making the CustomerOrderEventConverter emit strongly-typed events like OrderAcceptedEvent, OrderDeclinedEvent, and so on, will mean that when a new event is required, a programmer must change the converter and the code that maps from the event to a new notification message.

On the other hand, if we keep the converter code agnostic of context and merely map the data in the SQS message to a general CustomerOrderEvent, then when we have a new notification, we only need to add or change the code where we generate notification messages. 

It’s preferable to design our systems so that we minimise the number of places where changes must be made to accommodate a particular change.

As a rule, it’s better to make tightly coupled code changes in one place rather than in two or more widely separated locations. In other words, group together code changing for the same reason and separate code changing for different reasons—a restatement of the Single Responsibility Principle (SRP). 

Some violations of the SRP can be very subtle. One thinks one is doing the right thing, for example, by making the converter produce contextually aware and strongly-typed events. Yet, with this design, one unwittingly makes the system more difficult to maintain. 

Nobody said designing systems was easy.  ;-)