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.

Example:

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.

Is it normal for a domain expert to do class diagrams?

If a domain expert does class diagrams in the traditional sense^*, then the answer is “absolutely not”. You should resist this as much as you can, for everyone’s benefit.

I have been in a situation like that in a start-ups many years ago, where a very strong domain expert has been trying to map a business solution in very technical terms. The problem with that was that rather than explaining the business aspects that the team was to address, he provided lots of technical details of a solution that he built in the past. Eventually we agreed that he should explain to us what to do rather than how to do it, and together we made that project a success.

^* Class diagrams are very flexible. They do not necessarily have to reflect classes in the computer science sense of the word. You can re-use the same drawing technique (boxes, arrows, inheritance, and so on) to map out relationships among business concepts from the real world. In this case, using class diagrams by a domain expert would be appropriate.

The business analyst for my current team does exactly the same 🙂 I wouldn’t say it’s commonplace, but it is a typical flaw for someone with a technical background who evolved into a business analyst/domain expert.

There are many ways to model a domain, from UML diagrams to words on a whiteboard to drawings on a piece of paper. The important thing is not the model’s aspect but what it conveys. You should also keep in mind that modelling the domain is collaborative work and implies conversation between the domain expert and technical people. An environment where the business expert produces all the models (not to mention low-level technical models) alone and imposes them on the dev team seems somewhat dysfunctional to me.

Is it normal for a domain expert (not a developer or technical profile) to do class diagrams?

NO, it is not usual thing to encounter, however there are always some exceptions.

Domain expert may build UML diagrams to capture business process and actors involved in it. That probably would be the best helpful document they can make ready for the project architect and entire team. Because, having 80-150 page long documentation document is hard to grasp and visualize by reading. In another words, business workflow, data-flow and decision processes-flow should be captured by that person.

However, detailed class diagram does require technical knowledge set of DDD (Domain-driven design) or Object-oriented modeling with good understanding in Class diagram.

There are a couple of things in your description of the scenario that don’t smell right to me.

• Class diagrams are capturing only a portion of the domain complexity. They focus on the static structure and ignore behavioral aspects. I bet the class diagram looks a lot like a data model too. UML is not intrinsically bad, but focusing on class diagram only …it is.
• “they just have to implement the model” … 🙁 what sounds terribly wrong here is that you’re probably missing the conversation around the domain model. Domain-Driven Design implies a process of deep shared understanding of the domain, and the situation you’re describing is allowing developers to code without understanding the domain.

What kind of modeling should he be using?
The process of creating a model should be collaborative, meaning that there should be a conversation and 2-4 persons drawing models on a whiteboard, or sketching them on a piece of paper, or writing user stories, or quickly coding tests (normally in a quick feedback loop). This way, modeling is not a single person’s duty. As a consequence, the modeling technique used should be the one that allows better dialogue, meaning shared understanding and maximum amount of feedback from the Domain Expert.

I personally had good experiences focusing domain explorations on flow of Domain Events rather than the static structure of the classes. Models tend to be completely behavioral, allowing for a quicker understanding of the whole picture.

UML models (and ERD models) have types. The conceptual type (logical type) and the physical type. The physical type is what gets tuned and implemented. The physical model is driven from conceptual model. UML offers the modeler to specify great details in a concise way and is good for both types of models.

If the modeler knows what they are doing, the produced model could represent a correct specification. Whether that specification is qualified to be a physical model or not, well, this is a different story and depends on several factors.

When crafting a logical model, the purity of captured requirements may be accidentally sacrificed. The modeler may produce a non-pure logical model when he/she documents user requirements in the logical model, for example, when he/she resolves an m-m relationship. While valid, the original requirement is now lost unless the new resulting class is well documented. There are many similar situations that could result in specifications that are not traceable such as assuming Primary Keys. The other thing is that users, in general, may not be a able to review the UML diagram. So the UML diagram can’t replace user requirements specification documentation. This results in more work being done.

To summarize, you can have logical models capture the requirements but you should:

1. Have an agreed standard of documenting user requirements within the project.

2. Clearly identify roles and responsibilities in the project.

3. Differentiate requirements gathering deliverable from Physical design.

4. Ensure user requirements are traceable and that users can verify what they told the business analyst.