Modelling Guide

This is some general advice when it comes to modelling messages.

Party Neutral Documents

A message should be thought of as a communication that can be stored and read years later, perhaps by someone who doesn’t know the original context. It should be understandable as a standalone document.

Correlation

If the message is related to another message, is it the message that is related, or the contents of a message. Are they related by a message identifier only, or by real business data ?

Readability

Someone is going to read a message as modelled, as a matter of course, or as an exception to straight through processing. Further, it may be translated into another language or format. Model the content of your messages for presentation in logical order and groups. Some syntaxes care about the sequence and other don’t.

Consistency

Always check to see what has already been modelled, and make your model consistent unless there is a good reason to do it a different way.

Reuse by Building Block

ISO20022 models a different message for each type of communication.
Don’t be tempted to reuse a message for a different purpose. The message’s type is a signal indicating what pattern of communication is expected to happen next in a choreography.

If the contents of messages are the same or similar, but the communication pattern differs, then use different messages and reuse the same message building blocks in each, perhaps with additional business constraints for each type of message.

Reuse by Association

Rather than repeating information in a message, say it once and reference it by using an association.

Constraints

Remember to specify business rules as constraints at the appropriate level of the message. Constraints on types may be used for rules regardless of context. For example, that at least one of the elements is used. Constraints on an elements may be used for rules in that context’s use of a type.
Constraints may also be applied at the message definition level, to alloe for regional variations (flavours) that may prohibit or require features of the base message. For example, one on a payment message, one region may require, and another may prohibit, a debtor’s address.