Alexander The Great 

In the absence of a comment from anyone else... my view would be to keep it simple!  The more complex you make it... and you can get very complicated if you choose... the more likely it is you won't maintain it properly and it'll start to become a pain point for you.

So if there is overlap in the terminology between domains then you could keep one termbase with an attribute picklist to define the domains.  But even if I did this I'd be very wary of overcomplicating the picklist.  Do too much and it really will end up being less than useful for you. You'd also have to maintain filters to ensure you get good value from all this effort when working with the termbase in Studio.

If there is little overlap then maintaining separate termbases probably makes more sense.

I think you also have to take into consideration who the termbases are for and how many people are going to be contributing to adding terms, what controls do you have in place to ensure your structure is managed effectively.  All comes back to complexity for me.  I'd be asking myself the question all the time... do I really need this level of complexity?  Where's the value when it's right and more importantly what are the costs when it goes wrong?

Having only just seen this - I thought I would explain how I went about it for multiple customers in a specific field in the dim and distant past. Originally I had separate termbases for each customer, but like you I found having multiple termbases made it very difficult to keep them all up-to-date. In the end, I merged all the customer databases into a single one and used a customer field to separate divergent preferred usage between the customers.

I use this approach with attribute picklists to separate terminology by supervisory divisions - and have a few extra fields e.g. to help with issues about inclusive language and also accessibility. I did find that I did have a lot of superfluous fields after a while, and recently rationalised some of them (e.g. an abbreviation type field - intended for a mothballed QA idea I had) as the time needed to be invested was not worth it in the end.

As Paul mentions, the level of overlap is probably going to be key in your decision (e.g. in your example, having Subpodryadchik three times indicates that there might be some terms that are overlapping!)