[jonahx]

Non-facetious question: In what sense do you consider your solution simpler than the one suggested by the article? The only additional complexity I see in their solution is creating one more class, but that seems like a surface complexity.

I respect your opinion but it seems that you aren't really addressing the advantages the article is claiming their design has.

The likelihood of change is much different for the policies than for the basic domain model attributes of a ticket, and this to me is the key reason to prefer the policy design that I'd like to hear you address objectively.

Based on your comment about swappable policies, I'd guess that your position is to wait until you need to pull it out before you do. But if you can see a likely change coming and there is no cost to designing for it, why not do it? Is your bone of contention with the idea that we can assign reasonable probabilities to what is likely to change; with the idea that there is no cost to pulling the policy object out now; with both of those things; or with something else entirely?