Domain Modeling: how to do that?

1

This is something I was thinking about when I read @digital-ember discuss this in its introduction.

Domain Modeling seems something which is very valuable per-se, as colleagues inside the same organization could have different understanding of the same terms, because there could be problems arising from that and because a clear picture of the domain enable other things, from process mapping to create Domain Specific Languages or other tooling for the domain.

So I was wondering if there are metholodogies that you all use, or resources on this. Are there lessons learned or tips?
How do you interview people to understand the domain?
How do you write done a description of the domain?
How do you ensure this picture of the domain is correct?

2 Likes
2

Back in the day, I did some research on that topic in the context of game design, but only ever scratched the surface with expressing ideas.
I will try and address some of the questions you raised a bit later, when I have more time, but in general I’m afraid their is no silver bullet how to interview domain experts and how to carve out a common domain understanding. People are just too different to approach them in a standard way. The task is to be able to adjust on the individual circumstances.

3 Likes
3

Interesting, do you happen to have a pre-print I can take a look at?

Thank you!

Yes, you are right, but I was wondering if could collect some lessons learned and put together some general directions to share with other practicioners.

If someone want to build DSLs he can find (with some difficulties :D) material to learn the technical aspects, but then it is even harder to find material on domain modeling. If we had that it could also help to understand better how much important domain knowledge is, and help growing awareness about the importance of DSLs.

The good thing is that, given there is not great material available (at least, as far as I know), whatever we could put together would be already an improvement w.r.t. the current situation :slight_smile:

2 Likes
4

Hi,
as mentioned earlier, here are some more thoughts on domain modeling. I’m curious to read about other experiences as well.

The most important takeaways for me working in different projects where I had to identify domain abstractions are (and I’ll explain each point below in more detail):

  • Listen to the domain experts (obvious, but wait)
  • Doubt/Challenge the domain experts
  • Observe the domain experts
  • Know as much about the “consumers” of the domain model as you know about the domain model itself
  • Built prototypes / demos often and let domain experts try them out

Obviously, my findings are biased towards building languages with rich notations and for non-programmers, so nobody should follow them blindly. It’s also not a complete list, but I consider these to be most important for me.

Listen to the domain experts
Undoubtedly this sounds obvious. Talking to the domain experts is necessary to understand the problem domain, and I won’t suggest specific techniques how to do that, I don’t have a preferred way yet, it really depends on a lot of factors. I use “domain expert” incredibly broad here and don’t mean just the roles that you might built tools for. Usually everyone involved in the creation of a product or service might have information to share with you that helps you built the right tools.

The most important thing, as cheesy as it may sound, is to listen what they tell you, but also notice what they are not telling you. So it is important to ask a lot of questions regarding their business goals, the target group’s role inside the bigger picture, their inputs and outputs, etc. If they never mention problems with the tools they are currently using, ask them how they ended up using this specific toolchain and why they like it (or not?). If some use custom scripts and tools they built for themselves (sometimes in secret), investigate heavily how this decision came about. This sounds like a rare thing, but thus far, in all my projects, people have already been building their own tools in Excel, with Matlab, in Python, or what have you, to improve their workflows.

Doubt/Challenge the domain experts
People involved in a process long enough take it as the status quo. More often than not, established steps within a process, however, only exist due to makeshift solutions or the lack of the right solution and can therefore be eliminated completely if the new tools just skip or automate them.

This is certainly related to what I wrote earlier about investigating the domain experts, but I also mean to not always trust what you hear is required or true. I’m not saying people delibertaly lie to you (although House might disagree), but they often just are unable to see the forest for the trees (here’s hoping this idiom works in English as it does in German).

Observe the domain experts
More generally speaking, look into UX testing methods. This allows you learn even more about steps and things your target group might do without questioning it and therefore never telling you about it. Do it at the beginning to learn about the current tools and processes and do it with your own prototypes and the eventual product to incrementally improve it.
My wife’s a UX engineer, and I stole a lot of her approaches towards UX design for language design in the past.
This helped me tremendously developing ideas for the language notations and user interactions, instead of looking at documents like spreadsheets and Word files the target group might have produced before and just trying to copy the notations over. Trying to mimic old notations might be an okay approach for a first iteration, but personally, I think it is good to question them right from the beginning to avoid translating bad habits from before into the new tools you are trying to build.

Know about the “consumers” of the domain model
Whether or not your domain model produces configuration, code, readable documents, or anything in between: it is important to understand how it is consumed and why the expected format is as it is. Maybe the target is just an intermediate step anyway and can be skipped. Maybe different reader groups of some generated artifact are interested in different aspects and therefore one should generate different views upon the data? A lot can be gained if the consumers are investigated and understood as well as the domain itself, and it can influence the domain’s scope and shape.

Built prototypes / demos often and let domain experts try them out
Basically, this means to treat your languages and tools the same way as any other product where you benefit from an iterative approach with a lot of small increments.

7 Likes
5

Once upon a time… when I worked in Philips Research I was part of a team that was put on the topic of domain modeling. Unfortunately, I left the company around the time the team became a real organisational unit in itself, but if you want to know more of their results, try to invite Pierre America (still at Philips) to this forum.

I myself am using a mix of techniques in interviews that come from the time I worked together with MetaCase on a project in The Netherlands, and a practical implementation of Domain Driven Design. What it comes down to is that in interviews I first ask for a general explanation of what we are looking at to get initial concepts, and in the second round and beyond we identify concepts by talking through business processes or use cases.
Concept maps and object models for structure, and activity diagrams for behaviour descriptions are used to capture the results.
Verification is done by discussing the results with multiple stakeholders, and by revisiting what is discussed by switching roles: I explain to the stakeholder what I think is in the models, and we make corrections together.

DSLs can grow from there, as well as traditional OO designs - depending on the case.

6

Do you know how can I reach him?

7

If you ever find the time to share examples or describe your approach in more details I would love to read about it

8

I’ll get you his contact details.

Angelo Hulshout
angelo@delphino-consultancy.nl

1 Like
9

@ftomassetti as you may have seen already, Pierre’s contacts are in your e-mail. He’s very much interested in joining us here.

1 Like
10

Thank you! I block my email on the weekend but I will invite him on Monday, great news, thank you!

1 Like
11

it would be interesting to get the opinion of @pierre.america on this topic

12

Thanks for inviting me to this group.
I really like the guidelines by @digital-ember and I have a few points to add. Around 2000 I led a domain modeling activity for a family of complex medical systems. We reported on that in Springer LNCS 1951. Here are a few essential elements:

  • We worked in overlapping groups, where a core team was overseeing the consistency of the overall model (which was large and complex, containing about 1000 classes). For every modeling session the core team was joined by a team of experts on a specific topic, who could make sure that all the details on that topic in the model would be correct.
  • The specifications of the system family were written in English text. We strove to have every word in that text (except, of course, for the grammatical glue) explained in the model. Some tooling was developed to allow hyperlinks from all these words to their definition in the model, but in the end this was not extensively used. The principle, however, was considered very useful as guidance on what to include in the model.
  • The domain model itself was shared explicitly with the stakeholders. We used UML to formalize the model, but it was not necessary for all stakeholders to become UML experts. They could still read the diagrams, ask for explanation if needed, and provide valuable feedback on the model.

More recently, in 2014, I followed roughly the same approach, but for a much less complex system. Although I left that team a long time ago, that domain model is currently still in use.

2 Likes
13

I think Jennek Geels works on this. He did a presentation at MPS Meetup (https://www.youtube.com/watch?v=cE63tS8Gvek&list=PLQ176FUIyIUZkYM943mWBVgAvjgFLkvAP&index=5) and proposed something related for LangDev in April.

@ftomassetti I’ll provide you with his e-mail to invite him.

14

I think you are right that it would be interesting to hear his opinion. He is already a member @jennek.geels

15

Indeed I am working on a method to discover and capture domain models. In fact this is a method that I learned back in the 1990s and have been using on-and-off ever since. The company that created the method (KISS) ceased to exist in the early 2000s and all there is left is a small number of practitioners like me.

These days I am working with the lead architect of the former KISS company, Robert Deckers, to revive the method and to fix a number of flaws (after all, we are 25 years older and wiser now). Robert is doing a Ph.D. thesis with focus on underlying formalism and notation of a domain model, whereas I focus on steps and guidance of domain modeling as a process. Also I am implementing the underlying model in JetBrains MPS and I am using this implementation in my day-to-day work as domain modeler.

This work is limited to modeling system behavior, for example but not limited to interaction between products and their users. That seems to rule out aspects known as “non-functionals” but that is deceptive. When “repair-ability” is important, I would ask “what actions do you perform when repairing” thus taking a functional perspective on a so-called non-functional. That is really helpful to get a grip on any “…-ability” aspect. But that is another topic.

At this point in time there is little documentation of this process available. The best introduction is the presentation Niko refered to (slides are here). It contains a worked example of the discovery process in action, using the Domino game invented by Gerald Kristen from KISS.

I have played the KISS Domino game many times in the past 25 years, for very different domains and with very different participants (business process owners, interaction designers, developers, testers, …). My role would be one of moderator: I let the participants do the talking and I guide them by asking questions. It is their model, not mine. They have to own it. But the meta-model is my responsibility. In the first sessions, anything goes, we put domino pieces on the table in an associative and intuitive way, often not conforming to the schema. It is my role to ask questions in such a way that after a number of sessions the pieces converge to the schema so the model on the table can be captured in MPS and processed/transformed/etc from there.

The real challenge for me as a moderator is to find the proper sequence of questions. There are quite a number of guidelines we have identified over the years, and also a great many degrees of freedom. For example, in a group that is keen on business rules and decision tables, I might start there, only to have the participants discover that you need to fix the vocabulary used in the rules, leading to the discovery of actions and entities. Other teams might want to start with actions, then work on division of labor of the actors involved, and do the rules only at the end.

Think of the process as how you design a building. Surely you do not start with detailing the plumbing. But one team may want to start with the floor plan, where another does an artist impression from the outside first. But in the end both teams will have their plumbing defined.

As said it is my mission to revive this approach and document it in the public domain – but don’t hold your breath. There is a lot to recount and recollect and this will take time.

One more thing. For a particular product initiated 15 years ago, we chose a different approach. We would observe operators in Graphic Arts production for a full working day and capture what we observed using a method called Contextual Inquiry. A most valuable aspect of this approach is a structured debriefing where 5~7 people sit in and each capture an aspect of the observations (physical layout, production activities, coordination activities, norms & values, …) After some 8 visits the debriefers would do the model. We might have worked with the operators themselves, but we chose not to. This is a typical approach for product development (as opposed to bespoke development) where you have to define a product for a large group of customers and you somehow have to capture the common denominator. After 15 years we have done well over 100 visits Contextual Inquiry style. Highly Recommended.

3 Likes
16

Thank you @jennek.geels for this awesome contribution!

That is a pity, but I hope you will let us know as soon as more documentation is available. While “Kennis is Macht – Modeleren van kennis in acties en objecten” seems a great title, I did not manage to learn German living there, so I think it would take a few decades to me to learn Dutch.
Maybe it is worth ordering “Object Orientation – the KISS method”, assuming I can find it

This also sounds interesting, however most of the work I do is done remotely, so that could be an issue for applying this method.

I think that now we have a few resources on the technical aspects of building DSLs, but when people ask me how one define the concepts to model I wish I had a methodology to point them. And I wish I had that methodolody so that I could use it myself!

1 Like
17

This book is mostly about the underlying model and its notation, there is some info on ‘steps’ but none on ‘guidance’ I am afraid. It covers an initial version of the paradigm, which has been expanded in the “Kennis is Macht” book. Still an interesting read.

A good starting point for Contextual Inquiry is “Rapid Contextual Design” by Karen Holtzblatt et.al. It is a great How-To guide for running the process.

1 Like
18

As a follow-up, I would like to ask this forum a question about “engaging all participants”:

  • what informal tools do you use to collectively discover the domain model?

Domino is an informal tool, you can capture elements outside a schema. There are plenty of “sticky notes” based processes that have the same quality. Domino encourages participation, anybody can put down a piece and label it. Like the CRC cards we did back in my Smalltalk days. Like example mapping.

What is your favorite tool here?

19

Hi Jennek, welcome aboard. Good to read your post, it reminded me that I need to have a chat with Robert soon. It’s been a while since I spoke to either of you.

20

If at early stages, usually the most effective representation medium/tool has been a whiteboard or paper. Whiteboards gives the advantage for group work and erasing minor mistakes to keep things readable for all. These can also be used for sketching sample application as well as drawing a model for the sample application. The particular benefit is also that if existing visualizations or ways of working are already established these can be detailed with whiteboards too – and incorporated to the created modeling language(s).

Often thought, there is already some domain models available, and then starting with them is natural as they are already known in the company. Sometimes there is already parts of language definitions (grammar, metamodel etc.) available and then starting with these is natural.

Once key concepts have taken some shape – in any of the above ways – we recommend turning them to a metamodel with a proper tool. The main benefit of using tool is that ideas can be immediately tested by using the language – and the best this can be achieved when the language definition and the language use happens in the same environment. Iterations are then fast as the effort to create and test different language ideas is small (compared to build, starting to create examples again, sharing it to others etc.). This way the first version of the language is usually available within 1-2 days, and ready to use language after 10 days (as reported by language engineers in the industrial: ACM Models Conf, https://www.metacase.com/papers/effort-create-domain-cameraReady.pdf).

On “engaging all participants”, as the question was, the best I have seen is collaboration via tooling. In some cases, we have had several language engineers defining the language and then 10 others using it at the same time. Once the language definition is updated, everybody can immediately test it and feedback loops starts… It has been thrilling to follow how the group has discussed about the language definition each having concrete example on their own computer. For me personally, that has been the best way to engage everybody.

3 Likes