It actually depends on the level of details in the class diagrams and the way they are used.
An important distinction that has to be made: a UML class is not (necessarily) the same as a programming language class. It denotes domain concepts that may be implemented in many different ways (or not at all).
Defining these concepts is a job for the domain experts. The specific format in which they will do so doesn't matter too much as long as it is clear enough (that is the hard part). So, it may be a verbal description or, as in your case, a UML diagram.
Now the thing is that these UML diagrams your domain experts produced don't need and most of the time shouldn't be used as blueprints for the code. They are there only to make it possible for the development team to understand the business domain. Then, if they feel that it is necessary, developers (including the system architects) create a different model that also takes into consideration technical limitation which are not known to the domain expert. Also, the format of that model is not particularly important. It may be another UML model, but also it can be a combination of code and project documentation.
Consider a banking software system. In this case the domain expert is someone who has the expertise in banking. His job is to communicate the business requirements to the development team and may choose to do so by modeling the document flow used by the bank. Now, the thing is that these documents (in the form in which they appear when printed and filled out by hand) are typically extremely un-normalized and contain lots of redundant data scattered across different forms. The model produced by the domain expert may contain all these redundancies, but the model implemented by the development will typically eliminate them where necessary. Nevertheless, both models had their use in the development process.