In OOP terms, we are trying to achieve loose coupling between the PaymentOrder class and Supplier, see quote
“Two or more classes are said to have loose coupling when they do not rely on each other to operate. If one class cannot be created without creating another class first, for example, their coupling is said to be tight.”
It is obvious that the introduction of such a standard is possible only if sponsored by an interested software manufacturer, because the market for components / subsystems does not arise from scratch. 1C has achieved success in partner solutions with the status of “1C Compatible” Directory “Implemented solutions” (1c.ru) . But the solutions there are either additional subsystems for typical 1C configurations. Or independent solutions, but with exchanges for typical 1C configurations i.e. everything is tied in one way or another to standard 1C solutions. Compared to “free” software, this is certainly a plus in the direction of compatibility, but the limitations are clearly visible.
In theory, even 1C could develop the BSP and the 1C Enterprise platform with a full-fledged development in the ORM of relatively independent subsystems. But visually, in the style of RAD (Rapid application development), this requires effort, and not adding another “feature”. If we do it in the Java style, we will get a huge amount of code and the 1C system will no longer be RAD. You don’t want it, or do you still want it? I think that in Application Frameworks the emergence of such standards is more realistic than in Java standards. After all, Java and its competitors are focused on other goals than just application development. Subscribe to the next series “1C without limits” on our channel t.me/Chat1CUnlimited . I can post the code on a popular, but fully accessible analogue in the Russian Federation github.