The Rigidity of Design

When I design systems, I often focus on making them rigid.

From experience, the more rigid the design is, the more resilient it becomes for future extensions.

That said, making everything rigid is not always the right answer.

In this post, I want to organize my thoughts on what “rigidity” means in design.

Why Rigidity Improves Extensibility

By “making things rigid,” I mean practices like the following:

• Adding NOT NULL constraints
• Making things immutable
• Keeping maximum lengths for strings and similar fields as small as necessary

All of these are acts of adding constraints.

My mindset is: “Do not allow what is unnecessary at this point in time,” and apply only the minimum required constraints.

So why does this improve extensibility?

Because it reduces the scope of impact when changes happen.

Extensions involve feature additions and modifications. If you can clearly see the impact range, changes are not that scary.

On the other hand, a single change can sometimes break parts that seem unrelated. That means the impact range is not well understood.

The constraints listed above all work toward narrowing that impact range.

I believe reducing the impact range is a key element of design that remains strong under extension.

Differences in Rigidity

I used to strongly believe that table definitions should be rigid.

As mentioned earlier, that was to improve resilience for extension.

At the same time, I felt uncomfortable with situations where DB design was driven by the UI.

For example, the UI layer is relatively easy to change. Whether it is web, CLI, or desktop, changes in upper layers are generally easier than changes in lower layers.

Upper layers tend to depend on fewer things, while lower layers are depended on by many upper layers. Because of that, changing lower layers often forces updates in upper layers as well.

Of course, with proper layer separation, impact can be minimized. Still, structurally, lower layers are depended on by more parts, so their changes tend to have broader impact.

DB table definitions generally belong to lower layers.

Letting UI concerns drive DB table design felt like bringing too much upper-layer convenience into lower layers.

In other words, I started to feel that “rigidity” in table definitions and “rigidity” in UI were not the same thing.

What Was Mixed Up

As I thought more about this discomfort, I realized there are two aspects of rigidity:

• Semantic rigidity
• Structural rigidity

What tables should carry is semantic rigidity.

• This value is required
• This relationship must exist
• This state is not allowed

You could call these the application’s core rules.

By contrast, what UI carries is structural rigidity.

• In what order users input data
• Which fields are grouped and shown together
• At what granularity users edit data

Treating these two as the same kind of “rigidity” was, I think, the source of confusion.

What Was Being Dragged Along Was Not “Meaning”

When UI changes cause DB table definitions to change, in many cases the “meaning” itself is not actually changing.

What is changing is presentation and interaction flow. The domain meaning is often unchanged.

So if table definitions change anyway, that is not desirable from a design perspective. It happens when UI “structure” is applied too directly to DB table definitions.

• Making the UI model and persistence model identical
• Making screen structure equal table structure

This may look simple at first, but it mixes layer responsibilities and can hurt future extensibility.

Making tables rigid is not wrong. In fact, it is important.

What matters is that the target of rigidity is “meaning,” not “structure.”

If meaning is rigid, the UI can safely stay flexible.

Because consistency of meaning is guaranteed in lower layers.

For upper layers, where ease of change matters, having consistency guaranteed below is a major strength. In the long run, I feel this also increases the product’s fundamental robustness.

Closing

In this post, I organized my thoughts on rigidity in design.

It took me time to get here because I had mixed up different aspects of rigidity. But looking at it through responsibilities makes it much clearer.

If you think from the perspective of “What responsibility should the DB have?” it becomes clear that what should be rigid is not always “structure.”

This was a good opportunity to reconsider what should be made rigid.

The UI model and persistence model do not have to match. In many cases, it is better if they do not.

This insight may seem small, but it can become a trigger for changing the whole design.

Rigidity is an important idea that supports future extensibility, but if used incorrectly, it can become a constraint that holds you back. Keeping that in mind, I want to keep designing with clear intent about what should be rigid.