I think the better takeaway is that sometimes you should have the courage to design "ugly" data models if your domain demands it. Or put differently, don't let

I think the better takeaway is that sometimes you should have the courage to design "ugly" data models if your domain demands it. Or put differently, don't let language or database affordances dictate your domain models. There are many situations where either your own abstractions or the abstractions of the language sort of "project back" into your domain model and "suggest" certain features to implement or special cases to handle. E.g. if you modeled some state as a bunch of boolean (or enum!) fields, then the language suggests that every combination of those field values should map to some meaningful real-world situation. But there is no real reason to assume this! Sometimes one flag only makes sense in the context of another flag, sometimes a specific combination of flags could theoretically occur, but is uninteresting as a business usecase. The same can happen with self-designed abstractions and interfaces: If "everything" in your system is a CRUD entity, then there will be some temptation to think of some meaningful "update" or "delete" operation for every entity - even if no one actually asked for those features. In those situations, it's OK to declare certain combination of values as "invalid" (e.g. if isOpen is true, the isLocked must be false) or as "equivalent" (e.g. if isOpen is true, then isLocked is ignored).