DDD is intended to allow a large organisation to split itself into distinct domains. This allows parts to evolve and specialise apropriately.

Trandforming a company to this is not simple, especially if you are dealing with a multi-country company where each coutry has distinct needs.

There are several risks:

• Certain changes are slowed down as one team being too busy can block entire intiatives.
• Some issues can be seen by everyone to belong to someone else. This includes cross domain consustency issues.

Simon Wardley is writing a book Rewilding Software Engineering

The gist of this to use small specific tools to learn about behaviour or the structure if systems. This allows us to reduce the time to question and time to answer.

This led me to think where are the small tools that I have been using?

I lean heavily on diagrams. Mermaid, Plantuml and graphviz are my go tos. Other members of my team use Miro.

In the past spreadsheets would have covered this.

Another option that is useful in distributed systems are the observability tools. These can be used to find how frequently a known error condition has occoured.

We frequently build quick views to investigate production issues.

It is amazing how a few simple tools can allow you to build visualisations from data. I recently extracted the team and domain structure from our central security setup scripts. Its about 10 lines of sed/awk/grep/dot

In the past I have used neo4j to identify which project were currently using which version of our internal node libraries. This makes applying upgrades consistently across 80 git repos possible.

I have been adding a new feature to a graphql based application.

Normally there is a mix of frontend and serverside work required. The latest feature is an attempt to bring together disperate information in one place. For the first time I was able to add an entire feature purely in the front end.

This feels like a good solution.