This is an attempt to catalog and discuss general domain abstraction patterns that can fall apart (become a poor fit) down the road. It tries not to be language- or paradigm-specific. A brief list comes first, and then a discussion below that.

* '''Entity''' - We give fixed names to dynamic organizations of atoms (river, cloud, Bob, Google).

[deleted items that were the result of making false asssumptions as opposed to a way an abstraction could fall apart.]

Please clarify, Mr. Rude Deleter Guilty-Until-Proven-Innocent Person. YagNi dictates not to use a structure/technique/model more complicated than you need to based on EXISTING requirements. While I don't agree 100% with YagNi (experience overrides it often), it's not a "false assumption" to incorrectly predict the future. Nobody can predict the future with any accuracy.

["Predicting the future"?  In all three cases that I deleted, there would have been no need to predict the future if the assumptions hadn't been made.   "YagNi"?  The features were already there, just insufficient for the tasks that they needed to perform because someone assummed that they could get away with a crippled version.]

Somewhere there must be a miscommunication. If a tree will be sufficient for ''current'' requirements but not future ones that we cannot know about, then where is the "assumption"? Just because a tree is sufficient for today's requirements doesn't mean it will be sufficient 5 years down the road, for example. We could make it super flexible by using mass amounts of indirection, but then the system is over-complicated, and perhaps too slow, for given needs. GoldPlating has huge up-front costs. Even if I as a developer want GoldPlating, likely those paying me will not.

[If the requirements have actually changed, it wouldn't be surprising that abstractions that were sufficient for the requirements before the change would become insufficient after the change.  But what of it?  It makes no more sense to blame the abstraction in that case than it does to blame the color red because the requirements changed from "The case shall be red." to "The case shall be blue.".  (BTW, I am paid to find insufficiencies in the requirements.  Even when it's decided that making the assumption is worth it, every place I have worked for wants to know both under what conditions the solution might fail, and what they gained by that chance of failure.)]

"Blame" is not really the issue here. As I mentioned below, perhaps the focus should be changed to describing and documenting the common ways that abstractions often "fall apart" in practice. In other words, document change patterns that make known and common abstractions obsolete or insufficient. It's not about criticizing abstractions, but rather understanding their limitations via examples and/or descriptions for how they can "go wrong" in the future. If you have a better suggestion for representing such info, please let it out. -t

[If you want to talk about the strengths and weaknesses of particular abstractions feel free.  There are pages dedicated to that (see LimitsOfHierarchies).  If you want to talk about the EvolutionOfRequirements, I have no problem with that.  But, your language still indicates that you are blaming the abstractions.  You refer to the requirement changes with perjorative language such as "abstractions often 'fall apart'" and "they [abstractions] can 'go wrong'".]

Okay, I agree the wording is poor. I'll work on better wording. Now, can I have the deleted material back?
---------
'''Discussion'''

Re: "Entity"

Even "organism" has potential problems. Are regular intestinal bacteria part of "us"? We need them to digest our food; our biology depends on them. Or sperm and eggs? Any abstraction can fall apart. Perhaps this topic should be renamed to "HOW abstractions fall apart".
-------
See also: EightyTwentyRule