*This is the second part of this topic, you can find the first part here.*

# Maths (cont’ed)

## Abstract algebra

Another classical example of mathematical concept that I find insightful for modeling is the concept of Group in the field of Abstract Algebra. To be honest, I’d guess this is what Eric Evans had in mind when he talks about *Closure of Operations* (where it fits, define an operation whose return type is the same as the type of its arguments) or when he mentions arithmetic as a known formalism:

Draw on Established Formalisms, When You Can […] There are many such formalized conceptual frameworks, but my personal favorite is math. […] It is surprising how useful it can be to pull out some twist on basic arithmetic.

The usual integer numbers and their addition operation is an example of Groups that everybody knows (although integers are also examples of other kind of algebraic structures).

## Limits as Special Cases

Going further, the concept of *zero *and of limits such as *infinity *can be inspirations for your domain. Consider for example the domain element Currency, with values EUR, USD, JPY etc. Traders can typically request to monitor prices for one currency, but they can also request to see all currencies or none.

Just like mathematicians do when they invent limit concept such as infinity or zero (a special value that does not really exist in the world but that is convenient), we can expand Currency with the *Special Case* values ALL and NONE, each with their own special behavior, i.e. behave like any currency or none at all (typically this means their methods return true or false respectively all the time). Trust me, it is very convenient.

You’ll recognize that the *Null Object* pattern generalizes the very concept of zero for arbitrary concepts.

# Principles

## Dimensions in the domain

Something I clearly learnt from maths classes at school is thinking in separate dimensions, and how looking for orthogonal dimensions helps tremendously.

Given a cloud of concepts spread over the whiteboard, if you can sort them out onto 1, 2 or 3 separate dimensions (the less the better), and if these dimensions are orthogonal (independent to each other), then your design gets greatly enhanced, provided of course it still makes sense in the domain.

For example we may have a dimension that groups the concepts of user, user group and company, that is probably orthogonal to another dimension that groups the concepts of financial instrument, product segment and market. Once the two dimensions are identified, we’ll seldom discuss concepts from both dimensions at the same time, because we know that they are independent.

Yet simple, the formalism of dimension is valuable as an inspiration for supple design. Also once you think of explicit dimensions you may consider extrapolating known concepts such as ordering or interval, if they make sense for your domain. In other words your domain gets more formal, which at the end of the day, once coded, will means less code and less bugs.

## Symmetries in the domain

One of the biggest possible inspiration for Supple Design is the idea of symmetry, as Paul Rayner quotes from Eric Evans in the 5th part of his series: Domain-Driven Design (DDD) Immersion Course – Part #5

Use symmetry as principle of Supple Design

I love this idea! Indeed, great physicists like Murray Gell-Mann have discovered a lot guided by symmetry.

When you look at elements of the domain, you can choose to focus on how we deal with them, rather than looking at what they are. Considering each perspective in turn helps to find out what properties the domain elements may have in common (for more see don’t make things artificially different).

Sometimes concepts looks fundamentally different just because some of them are singular whereas other are plural. The Composite pattern offers a solution for that. You can unveil symmetry just by looking from the right viewpoint.

# Deeper insight than the domain experts?

Domain-Driven Design advises that the domain shall not deviate from concepts and ideas that the users really know and really talk of. However it may happen that by analysing the domain you uncover structures than the people in the business are not even aware of. In fact they may well manipulate the structure in practice without being conscious of them.

I’ve come across such a case in interest rates derivatives trading, where swap traders think of spreads and butterfly as products by themselves, and intuitively know how to combine them for their purpose. However when you want a machine to manipulate these products, you’d better formalize a bit the concepts, that are otherwise intuitive. In our case, simple linear combinations proved to be a good formal framework for spreads and butterflies, even though hardly any traders speaks of the topic like that.

## Influences everywhere

I recommend browsing various fields for behaviours or structures that look similar to the domain being modelled. This yields benefits even if you don’t find a corresponding structure, since when you compare your problem to another one you must ask good questions that will help get insights anyway.

With some practice you may even anticipate, and whatever concept you encounter gets automatically “indexed” in your brain just in case you would need it later. No need to remember the concept, just that it exists.

What’s important is not that you know everything, there are books and Wikipedia for that. What’s important is to be ready to dedicate some time looking for a formalism that is well-suited for your domain.

The more demanding you are when making the Design Supple, the more reward you’ll get over time, and by this I mean less ad hoc adjustments, error corrections and tricky handling of special cases.