# Modelling Is Everything

DevFeed: [Modelling Is Everything](<https://devfeed.tech/articles/modelling-is-everything-13616.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/09/modelling-is-everything.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-09-02T18:23:00Z

Content type: opinion

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Domain-driven design (DDD)](<https://devfeed.tech/topics/domain-driven-design.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Development](<https://devfeed.tech/topics/development.md>), [Code](<https://devfeed.tech/topics/code.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [ddd](<https://devfeed.tech/tags/ddd.md>), [design](<https://devfeed.tech/tags/design.md>), [development](<https://devfeed.tech/tags/development.md>), [domain-driven-design](<https://devfeed.tech/tags/domain-driven-design.md>), [modelling](<https://devfeed.tech/tags/modelling.md>), [performance](<https://devfeed.tech/tags/performance.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The article argues that modelling what needs to be implemented is the most important step in software development, especially when building high-performance systems. It connects Domain-Driven Design with modelling the problem domain and explains that understanding CPU, memory, storage, cache, and network behavior can improve correctness and performance.

## Source excerpt

I'm often asked, "What is the best way to learn about building high-performance systems"? There are many perfectly valid answers to this question but there is one thing that stands out for me above everything else, and that is modelling. Modelling what you need to implement is the most important and effective step in the process. I'd go further and say this principle applies to any development and the rest is just typing :-) Domain Driven Design (DDD) advocates modelling the domain and expressing this model in code as fundamental to the successful delivery and ongoing maintenance of software. I wholeheartedly agree with this. How often do we see code that is an approximation of the problem domain? Code that exhibits behaviour which approximates to what is required via inappropriate abstractions and mappings which just about cope. Those mappings between what is in the code and the real domain are only contained in the developers' heads and this is just not good enough. When requiring high-performance, code for parts of the system often have to model what is happening with the CPU, memory, storage sub-systems, or network sub-systems. When we have imperfect abstractions on top of these domains, performance can be very adversely affected. The goal of my "Mechanical Sympathy" blog is to peek at what is under the hood so we can improve our abstractions. What is a Model? A model does not need to be the result of a 3-year exercise producing UML. It can be, and often is best as, people communicating via various means including speech, drawings, illustrations, metaphors, analogies, etc, to build a mental model for shared understanding. If an accurate and distilled understanding can be reached then this model can be turned into code with great results. Infrastructure Domain Models If developers writing a concurrent framework do not have a good model of how a typical cache sub-system works, i.e. it uses message passing to exchange cache lines, then the framework is unlikely to