6

The domain expert in our team uses UML class diagrams to model the domain model.

As a result, the class diagrams are more of technical models rather than domain models (it serves of some sort of technical specifications for developpers because they don't have to do any conception, they just have to implement the model).

In the end, the domain expert ends up doing the job of the architect/technical expert right?

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

If not, what kind of modeling should he be using?

Matthieu Napoli
  • 615
  • 2
  • 6
  • 13
  • It is a bit odd, but this could be a good thing - is there a particular reason why you are asking this question? Is this person overworked, or producing sub-par technical models? Unless you have some kind of need for formal separation between those roles (since this person is performing two roles), I actually have no problem with this kind of setup, if you're lucky enough to have it. – Daniel B Oct 04 '12 at 13:13
  • Does he model really class diagrams (with methods he expects to be implemented by you), or only ER diagrams in UML notation (classes = tables, attributes = table columns, methods only for documentation without the expectation that the devs should implement them 1:1)? The latter may be acceptable if your domain expert has some data modeling background, the first almost always not. – Doc Brown Oct 04 '12 at 15:08
  • @DocBrown this is the first case, the UML models are used as "technical specifications", this is why i thought this might not be optimal – Matthieu Napoli Oct 04 '12 at 15:54
  • @Matthieu: do you really believe if your domain expert would use a different form of specification (instead of UML), this would make a real difference? You have to make consensus with him who is responsible for the technical parts of the program design, and where you draw that line. This has *nothing* to do with UML. – Doc Brown Oct 04 '12 at 17:10
  • 1
    @DocBrown "The latter may be acceptable if your domain expert has some data modeling background" sketching a domain model with a Data Model in mind is a sure way not to do Domain-Driven Design and also not to come up with a significant domain model. :-/ – ZioBrando Oct 05 '12 at 12:31

6 Answers6

8

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.

Goran Jovic
  • 2,748
  • 23
  • 28
  • Yes, if the diagram contains DomainModel. - No, if the diagram contains Infrastructure. - Ie: It's perfectly okey to have "Train", "Wagon" and "Loco" from the domain expert if you are in the rail industry, but incorrect to get "DoctrinePhpTrain" or "LocoInJson" for example as that is infrastructure and out of the domain model. It is even okey to get domain Exceptions, Events and even separation from what's Entity or Value Objects. But only if they are "domain" bounded. It would be incorrect to get specification that the Event must be queued into a RabbitMq. – Xavi Montero Apr 03 '16 at 23:44
4

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.
Sergey Kalinichenko
  • 17,393
  • 4
  • 57
  • 73
  • 1
    The "he provided lots of technical details of a solution that he built in the past" is a recurring anti-pattern. It shows that the person is not the best Domain Expert available. – ZioBrando Oct 05 '12 at 06:55
  • @Ziobrando you would be surprised how many domain experts confuse how and what they do. It's just 'doing' to them. – AndreasScheinert Oct 05 '12 at 09:20
  • I won't be surprised... :-) Well in fact we shouldn't expect it either! That's the reason for having a conversation, we need the conversation also to clarify and distill the knowledge domain experts usually have in raw, unstructured form. – ZioBrando Oct 05 '12 at 10:33
2

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.

guillaume31
  • 8,358
  • 22
  • 33
1

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.

Yusubov
  • 21,328
  • 6
  • 45
  • 71
1

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.

ZioBrando
  • 1,494
  • 10
  • 9
0

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.

NoChance
  • 12,412
  • 1
  • 22
  • 39