Show Cover Slide

Let's Not Instrumentalize Philosophy – At Its Core, It's About Communication (feat. DDD)

gpt-4-turbo has translated this article into English.

Modeling is a Conversation. Structure is Merely the Outcome.

Recently, Domain-Driven Design (DDD) has been frequently mentioned in various communities and practical fields.
This is deeply related to the changes in product development approaches.

Breaking down complex systems,
structuring around domain models,
and aligning language—this approach
may seem like the ‘correct design methodology’ to many.

However, I view DDD from a slightly different perspective.

Where traditional waterfall methods emphasized procedures and documented plans,
in a startup environment, rapid feedback loops and flexible responses have become important.
In this change, the importance of communication is being emphasized again,
and in this flow, DDD is gaining attention.

Strictly speaking, DDD is not a tool.

DDD is a philosophy of design,
and the core of this philosophy lies in ‘communication’.

Dividing the domain,
defining boundaries,
standardizing terminology—
all are ultimately means to align human thoughts and facilitate communication.

Focusing on structure, layers, and patterns while overlooking this point can lead us away from the essence.

Personally, I am organizing the language within the team centered around the expression system of Service, Feature, Function.
This may overlap with the concept of ubiquitous language, but it provides clearer and more practical standards.
What matters is that whatever the mode of expression, the thoughts of people and the structure of the system should be aligned as closely as possible.
In this process, DDD should be a philosophical aid rather than the goal.

The systems we design are structured results of human thought.

Code is the medium that contains thoughts, and the system is the structure in which those thoughts operate.
In this context, design is essentially ‘conversation’, and modeling is merely the result of that conversation.
Complex explanations and concepts are just inevitable products to reflect human thoughts more precisely.

The result of expressing system thinking in language becomes the design pattern, and the system design.

Integrating language alignment into culture and systems is a very attractive endeavor.
This is why designers should not remain mere technicians who create structures, but should be interested in thought and philosophy.
I believe this is the essential role that design must perform.

Therefore, language alignment is most crucial.

This alignment alone can solve many communication issues.

In the past, we consistently tried to align language through methods like functional specifications, feature lists, and feature catalogs.
These efforts faded as startup culture settled in,

and priorities shifted towards rapid development and modularization,
resulting in the breakdown of language alignment between domains.
I think this is one of the reasons why DDD is being emphasized again.

And the necessity of this language alignment should not be introduced in practice as a one-off or solved with a specific tool.

This is not an issue that can be resolved with design tools or techniques,
but a problem that requires leadership to provide direction and standards.

DDD may not be a new concept but a movement to return to the basics of `language alignment’ that we’ve lost.