This is the second presentation, introducing a single idea on designing for the unexpected in practice.

1. Problem domain models
Design for the unexpected
How to implement it in practice – 2
Paul Valckenaers

2. Objective
• Reveal how problem domain models may enjoy
unparalleled coherency and consistency,
even when developed independently
• How this enables in-depth interoperability
• Prepare the audience for the next presentation(s):
Implications for the design and implementation of
domain models
Necessity to adopt the proper not-quite-mainstream
software tools to build suitable models

3. Reality is coherent and consistent no matter what …
By Thue - Own work, Public Domain,
https://commons.wikimedia.org/w/index.php?curid=164725

4. Real-world coherence and consistency
• Reality always remains coherent and consistent
• Often in an undesired state or manner
• E.g., 2 cars cannot occupy the same space at the same time
• Problem domain models must mirror this reality
• Also in these undesirable states
• What the user/customer wants (or pays for)
must not limit what is covered by the model
• Relevance (to the user requirements) has an impact
• Coarse modelling commonly suffices for undesirable states
• Hence, model development efforts may remain (very) low

5. In-depth interoperability
• True interoperation (i.e. in-depth) happens in reality
• When 2 or more IT systems co-exist, the interoperation
that matters occurs in the world-of-interest, in reality
• Properly designed problem domain models reflect this
• Suitably designed domain models inherit/mirror the
consistency and coherence of the corresponding reality
• Superficial interoperability (i.e. common understanding)
• Often needed to enable effective interoperation
• Becomes (almost) trivial when in-depth inter-
operability has been achieved (first)

6. In-depth interoperability
• Analogy: in-depth interoperability (on its own)
• Organise a soccer tournament
• With soccer teams
• Speaking different languages
• Analogy: superficial interoperability (on its own)
• Organise a football tournament
• With football teams
• All speaking English
• But playing European (soccer) and American football

7. In-depth interoperability
https://commons.wikimedia.org/wiki/File:Caleb_Mendez_Soccer_
09.jpg#/media/File:Caleb_Mendez_Soccer_09.jpg
https://commons.wikimedia.org/wiki/File:Arian_Foster_fumble.jpg
#/media/File:Arian_Foster_fumble.jpg

8. In-depth interoperability
• The problem domain model is a survivor
• When an interoperability, cooperation or integration
effort experiences a conflict, the problem domain
model remains intact.
• When the traffic map indicates the actual road capacity,
it may be involved in a conflict (e.g. insufficient capacity).
• Changing the problem domain model will not solve such
a conflict. Indeed, adding capacity on the map does not help.
• A problem domain model implementation, designed
for the unexpected, tracks its corresponding reality.
When the road capacity is increased in reality, the
model will be updated, reflecting even the temporary
decrease in capacity caused by road construction work.

9. In-depth interoperability
• The problem domain model and continuous improvement
• When an interoperability, cooperation or integration
effort experiences a conflict, the problem domain
model may provide additional services.
• When the traffic map indicates road connections and
road segment lengths, a cyclist application may require
information about those roads going up and down.
• Such changing of the problem domain model only improves it.
The existing users will not notice the change, unless they
benefit from the upgrade.

10. Discussion
Problem domain models (ought to) reflect the corresponding reality to
an extent that they inherit their coherence and consistency from reality
In a manner, God becomes a member of the design team, a valuable member bringing
coherence and consistency, even amongst systems that are developed independently.
But God is not a team player. Taking instructions is not an option. God’s contribution
has to be accepted without questioning, without modification… if the interoperability
benefit is to be preserved. Such “attitude” will be unacceptable to many team leaders.
Indeed, there is no such thing as a free lunch. To enjoy in-depth interoperability (i.e.
coherence and consistency), incorporating problem domain models within an overall IT
system or infrastructure imposes its own requirements.
In particular, modelling tools/languages/… cannot compromise on their expressive
power. Moreover, deciding what may become part of a domain model can be tricky
or subtle. This will be addressed in forthcoming presentations.