Already a subscriber? Jump ahead to the good stuff!

But if someone forwarded this to you, they probably love It Depends and think you would too! 

Hello Everyone!

Welcome to the 52nd episode of It Depends. Hope you are all doing well. This week, I look at an interesting pattern of system evolution and then share the best of the internet as usual.

The pentagon of entity modelling

You can read the original article directly on the blog.

I recently read an article by Matt Ricard about the "Heptagon of Configuration" in which he discussed how configurations evolve in a cycle.

It struck me that there's another thing that follows a similar routine - entity attributes. Entity attributes often grow into entities in their own right.

• Tax number grows into tax records and engines.

• boolean flags grow into multi-valued state machines etc

The entity evolution cycle

This is the transition as I've seen it go in my experience.

• Some new, urgently required properties of an entity are modelled as a hack in a configuration somewhere.

• This configuration is then pulled into the entity's main data mode, typically as a boolean attribute.

• Boolean attributes evolve into named/enumerated types, sometimes with more associated data.

• Enumerated types become full-fledged entities linked to their previous host entity

• Entities evolve into complete business domains with their systems, process, almost organizations.

Why?

This iterative process happens because as we explore more use-cases, a more and more complex domain model emerges. The pentagon of entity model evolution is just a sign of developers continuously trying to keep up with a deeper understanding of the business but not yet knowing enough to model its nuances fully.

I interpret technical debt similarly - as wisdom in hindsight. The system's implementation is essentially just catching up with the developer's understanding of the problem domain.

This is a perfectly safe, natural way for systems to evolve. But if you want to crank the wheel a little faster, the only way to move fast but stay on track is to spend more time understanding the business domain upfront. Understanding the domain better can help us predict future needs and build the necessary extensibility, if not the actual capabilities in our designs right away.

From the internet

1. For me, this article/talk by David Rosenthal is the last word in debunking the utter bullshit of the crypto-blockchain ecosystem. It is a technical, meticulous, and brutal takedown of the so-called decentralization of Blockchains.

2. Brian Footer and Joseph Yoder of the University of Illinois (UC) have written a paper on the architectural pattern known as “big ball of mud”. Odd as it may seem, it proves that everything can have pros and cons if you look objectively enough.

3. Efe Karakus wrote this fantastic Twitter thread on building client-side platforms.

That’s all for this week folks. Have a great weekend.

-Kislay

If you love reading It Depends, consider supporting it on Patreon, Gumroad, or Buymeacoffee