Clean Code: Focus on WHAT, not HOW

How to create software that speaks the language of the domain

50% OFF - The Complete TDD course

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Motivation

You are not paid to write code. You are paid to solve problems. Half of the solution is understanding the problem. When it comes to producing quality software, you need to focus on two things:

• doing the right thing

• doing the thing right

In this particular order.

Our code should reflect the business problem it solves. When it uses clear names, a clean structure, and focuses on the domain, it’s easier to discuss, maintain, and improve it.

In this article, I’ll share 3 tips on naming, structure, and testing to help you focus on WHAT the code does—not HOW it does it.

Avoid Names With Technical Jargon

Avoid using names with technical jargon. DTOs, flags, and records are all related to specific solutions on the computer.

Instead, use names that speak about the problem. If a name contains technical terms, it is probably focusing on HOW.

Clean code focuses on WHAT.

Use Screaming Architecture

If you look at your application and you only see folders like these:

Then your app doesn't tell anything about the problem it solves. It's driven by technology instead of the domain. If you want to add a new feature, you need to add files to all these places. Features are mixed, leading to maintenance hell.

Now look at this folder structure:

It is called screaming architecture. It is easy to navigate, with clear domain separations. If you want to add a new feature, you just add a new main directory. It has better discoverability and results in a low entry curve for new developers.

A clean folder structure is like a well-organized room; everything has its place, and it's easy to find what you need. Your folder structure should communicate the domain, not the technology.

Write Behaviour-Driven Tests

Many developers get this wrong about Unit Tests:

• ❌ A class is not a unit

• ❌ A function is not a unit

• ❌ A module is not a unit

The "unit" does not refer to code structure. It refers to a single, observable business behavior.

The strength of the Chicago School of Test-Driven Development lies in prioritizing behavior over isolated components. It focuses on the WHAT, not the HOW. It leads to robust tests that support refactoring.

Don't write tests when you create a new class. Write tests when your system has a new behavior.

Conclusion

Clean code is not focused on implementation details. It is focused on solving the domain with clean naming, expressive folder structure and behavior-driven tests.

To learn how to write clean code and behavior-driven tests with the Chicago School of TDD, check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The two schools of testing with the 5 types of mocks

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.