Dangers of DDD in a Medium to Large Org

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.

Rewilding Software Engineering and Observability Tools

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.

The power of graphql

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.

Credit Rating Agencies

These are the companies that help other companies know if a customer is who they say they are and are creditworthy.
When a company reports a payment the data is updated fairly quickly, typically within days.

Correcting mistakes takes significantly longer. I have been subject to a fraudulent credit card application. One of the three credit agencies is dragging their feet on correcting the data. The promise is 2 months to resolve the issue. It is taking significantly longer than that.

Unless you are a paying customer of the agency they won’t even discuss problems with the data that they hold.

Applying Hindu Theology to Software

In Hinduism, the “creator, destroyer, and preserver” gods are Brahma (creator), Vishnu (preserver), and Shiva (destroyer), collectively known as the Trimurti, representing the three primary aspects of the divine in Hindu belief. 
Explanation:
Brahma:
The creator god, often depicted with four heads symbolizing his ability to see in all directions.
Vishnu:
The preserver god, responsible for maintaining balance and order in the universe.
Shiva:
The destroyer god, associated with transformation and the cyclical nature of life, destruction being necessary for new creation. 




Wikipedia

Software development is very focused on the creator part. Preserver covers maintance. We don’t talk much about the destroyer.

I did once worked with a developer that took the approach that unit tests were the preserver and anything that did not break a unit test was subject to deletion. This works well in high code coverage cases.

Once I saw a codebase that had been built by copy paste have 2/3 of the code deleted. We were maintaining miltiple copies of various things. The compiler was able to help find unreachable code. Its amazing how productive you become after

At all levels of a system we should know what a component is used for. Find something that is sponsoring it being kept around. These will form chains so we can eventually link it to a user need. If a component does not have a useful purpose then it can be deleted. This is much easier to maintain if you are using outside in  design.