Discussion about this post

User's avatar
Sean Corfield's avatar

This is great stuff. At work, over time, we started with a Boolean flag for one aspect of a member profile, and later had another slightly related Boolean flag for a different aspect of a member profile, then we realized we needed to synthesize a new status from the two Booleans -- a three-state status. And of course now we have four possible states where only three are valid.

We did exactly what you advocate here: we introduced functions to "get" and "set" the status and replaced references to the old fields with calls to this status function. Later we modified the "getter" to heal the profiles that were in that fourth, invalid state -- because of course that happened to us, despite it "not being possible". We still have the two underlying Boolean columns in the database -- we didn't feel it was worth the time and effort to add a new status column and migrate the old flags into that...

Our database schema dates back to 2012 at this point, and it's been heavily modified over time as business requirements have changed, so it has a trail of now-incorrectly named and/or unused columns -- which we paper over in the code, to maintain the accuracy of the domain model's evolution.

For example: in our legacy (pre-2012) system, members could "wink" at each. Then business renamed that action to "flirt" (with a slightly different set of rules), then it got changed to "like" with a reciprocal "connection" state, and then the rules changed to withhold delivery of likes until the initiating profile was approved, etc. We did a database migration from flirt to the initial version of like, and then built functions to support the domain for everything else.

Expand full comment
Michał Moroz's avatar

That was part of my talk I presented on a couple of conferences. I showed the connection between removing "not-reflecting-reality" states in the model of the reality and simplicity in reactive programming. At the end if we can remove such states from the program, that program would have less errors and less complexity. :)

In reactive programming it's even more important to do that early (e.g. at response from API)

Expand full comment
4 more comments...

No posts