DDD-Software Design: A Two Person Job

In the previous blog, I described what happened Domain Driven Design met Deadline Driven Design? Software design is a complicated activity. Pushing the deadline doesn’t work in most cases, cutting the software design will never work.

Not Existing No-Design-Software, It’s Either Good or Bad

Let’s first explain what I call the two person job in my previous blog. Let’s answer a basic question first.

Who designed your software?

A, UX designer; B, Architect; C, BA; D, Developer;

If you choose A, I would argue with you by Steve Jobs Quotes

“Design is not just what it looks like and feels like. Design is how it works.”

If you choose B, I would argue that building software is not like constructing a building. It’s much more complex, you can’t copy and paste a lot. Constructing a building usually can be breakdown into duplication works which can be executed well with workers. However, when software is broken down into user stories or tasks, they are very different and need so much intelligence. Some development teams don’t have an architect role at all.

What happens when BA designs the software?

What I found in my personal experiences is when BA is keen on giving suggestions or estimation in technical details, their contribution to software design and implementation quickly become chaos or be treated as a conspiracy act. They either overlook the technical risk or their technical knowledge is decayed.

So, is it the developer doing the design job? Yes and No!

Alberto Brandolini, the creator of event storming once said:

“It’s not stakeholder knowledge but developers’ ignorance that gets deployed into production.“

Make no secret, I think a lot of existing software was built and “designed” by developers but unconsciously. After a developer accepts a user story, a continuous mind-flow is going through a developer’s mind to their hands and reaching to their keyboard and flowing into code repository days and nights even s/he usually doesn’t realize when and how they did the design.

However, unfortunately, even in a comfortable timebox, the design work does not always end up in good hands?

Although developers usually are very intelligent types, they would get lost in developing the user stories like stuck in a maze when they don’t see and understand the whole picture of the system. They are more interested in new tools and cutting edge ways of doing things instead of absorbing and reflecting the business requirements.

So my answer for software design: It’s a two person job.

In my software development and consulting career, I do see a few shining moments, when BA was working together with developers to create very good software design activity and conversations. Sometimes BA was drawing their mind in a piece of paper with endangered UML language; sometimes BA was doing a role play to explain the business scenario, the developers pick those messages up and translate them into some workable software. Harmonious!

OK, so how do we know a software design is good or bad?

The Fortune (Software) Designs Have Their Own Beauty, but All Unfortunate Designs All Alike

All unfortunate software designs usually would all come to a dominant architecture “ BIG Ball of Mud”.

There are many forces contributing to the “dominant architecture”, let’s focus on the complexity trait of the forces.

“Complexity: One reason for a muddled architecture is that software often reflects the inherent complexity of the application domain. This is what Brooks called “essential complexity” [Brooks 1995]. In other words, the software is ugly because the problem is ugly, or at least not well understood. “

— described in http://www.laputan.org/mud/mud.html#Forces

A common misunderstanding is that adopting a microservice approach is going to escape the curse of Big Ball of Mud architecture.

MSA is Ops wised. It has advantageous in release and deployment.

However, regarding complexity, microservice is a double-edged sword. On the one hand, microservice style could split the size of the complexity, and separate them into different code repositories and processes etc. On the other hand, it added some extra complexity for MSA management. Let’s put the “technical complexity” for a while and focus on the “essential complexity” itself instead of technical complexity like MSA management stuff.

Does MSA really help solve the “essential complexity” of your software? No!

MSA is brought out to solve fast delivery problems and operating scalability problems. Without a good domain model, recklessly adopting MSA, you are very likely to get a grid of small balls of mud instead of one big ball of mud.

Tackle the Essential Complexity

Reduce Misunderstanding by Conversation Instead of Documentation

The application domain is inherently complex, sometimes you can change it , sometimes you can’t. So a good strategy is to reduce or even eliminate the misunderstanding. Make sure you don’t create more complexity or misunderstanding to the inherent complex domain.

A good conversation between domain experts and developers is the best way to eliminate the misunderstanding of the application.

One of the most important features of Event Storming and DDD is to enable communication between domain experts and the developers.

Look back why the waterfall design process does not work in software design, BA and developers work in different silos. BA came up with a very long Product Requirement Documentation and then passed it to the developer team. There is very little knowledge sharing and effective conversation regarding the software design and understanding.

Individuals and interactions over comprehensive documentation

Stop Talking About Technical Complexity

A very common bad practice is to talk about technical details in DDD conversation. Remember DDD is technology agnostic.

Compared to domain complexity, technical complexity is easy to manage and usually has some fixed pattern to follow. Please don’t want to waste the energy and mix the technical complexity into domain complexity. Besides, technical complexity is not a two person job. Bringing it up into the conversation would create confusion.

Besides the conversation and domain model itself is highly evolving, so talking about the implementing details sometimes is just meaningless when the domain changes.

Having said that, be ready to pacify people’s technical and implementation impulses during the DDD and event storming activity.

Visualize the Understanding

That’s a main feature of event storming. Spread all the events, commands, aggregates etc into the walls so that everybody can see it and change it. Visualization is powerful. No matter physically or virtually, it’s very helpful for people to understand the whole process and interlock between different parts.

Sometimes people could visualize it in different ways, eg drawing the diagram in a paper, or using UML tools, doing a role play to mock the business process is also a good idea.

Continue Questioning and Iterating the Understanding

Rome wasn’t built in a day, so the application domain won’t be understood in one conversation.

It is not surprising that there are a lot of questions and misunderstandings between technical brains and business brains.

Don’t be frustrated if there are too many questions. That’s the whole meaning of DDD.

If nobody knows the problem, we should mark it for later or pick up the phone calling the end-user.

On some occasions, developers don’t like to ask questions to the area they are not familiar with. What I usually do is to call the roll to ask questions and make sure everybody is on the same page.

Usually the application domain is very large and complex, so instead of doing it all for once, we should do it iteratively. Otherwise you won’t be able to deliver anything for a long time.

In this article, I mainly talked about why DDD matters in the software design domain and some practises of doing it. In my next one, I would try to explain a swiss army knife of DDD event storming and how to make it more productive.