I&#x27;ve been thinking about this problem lately, and I thought the article gave it a good treatment.  However, the problem I saw is that unless someone has already used the right provided language primitives for their data, you suffer the expression problem again anyway.<p>A pattern that I believe can help solve even this level of expression problem is the facade pattern (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Facade_pattern" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Facade_pattern</a>).  In other words, to expand upon what has existed before, one writes a layer on top of the third-party package that belongs to the current project.  That layer implements, by default, everything in the external package, and it gives you the ability to extend it as you see fit.  In addition, you get all the other benefits of the facade, like being able to swap out, fix, or extend specific implementation details without having to alter many places in code where you relied upon some external package&#x27;s API decisions directly.<p>For me, it&#x27;s still a thought experiment.  I do not have a lot of personal experience trying this methodology out in the extreme in production.  Has anyone else tried it and can comment?