We had the same problem, and still have. and working gradually to reduce them.
Started with Country, then State, then City, and so on ...

The higher commom records on tables on top of the Relationship structure , the higher are the chances of long lockwaits, or locktimeouts, or even deadlocks.

At @raveen

Nicely done !

We have implemented a similar approach here as well, with 2 or 3 set's of DD subclasses for each table.

1st layer are just "cosmetic" stuff, labels, column formats, but no relationship defined at this layer of dd classes. (this one is rarelly used,, only on certain views that only requires read-only information)
2nd layer, implements validations and some basic business rules. but no relationhip defined as well.
3rd layer, implements relationships via dd-Relates, and complex validation rules that deppends on ohter "related" tables.

And we play with them, when buiding the views DDO structure , reducing a lot the required size of the Structure.. like in your case example.. If when doing an insert in a ORder-Line row, and we know that the customer, and all other higher tables in the hierarchy won't be changed, they don't even appear in the DD structure at all, so, they are never locked. .

Thanks for sharing it..