RDRA/ドメイン駆動設計(DDD)/ICONIXでDomainをEnableにしよう

マーチンファウラーが書いたDDDの序文を翻訳してみました。
（素人なので、変なところはご容赦を。原文から読み替えてくださいね。）

ドメインモデルを作ることの難しさや価値について書いています。

There are many things that make software development complex.
But the heart of this complexity is the essential intricacy of the problem domain itself.
If you’re trying to add automation to complicated human enteprise, then your software cannnot dodge this complexity — all it can do is control it.

ソフトウェア開発を複雑にするものはたくさんある。
しかし、この複雑性の本質は、主にドメイン自身の複雑さの問題である。
もし、ややこしい人間企業にオートメーションを追加しようとするなら、あなたのソフトウェアは複雑性を避けられないだろう。–できるのは、複雑性をコントロールすることだけだ。

The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure,
which gives the software developers the leverage they need.
A good domain model can be incredibly valuable, but it’s not something that’s easy to make.
Few people can do it well, and it’s very hard to teach.

複雑性をコントロールする鍵は、よいドメインモデルだ。そのドメインモデルを基本的な構造に取り入れることによって、モデルはドメインの表面上のビジョン以上になる。
そして、ソフトウェアデベロッパーに彼らが必要としている効力を与える。
よいドメインモデルは、ものすごく価値がある。しかし、それは簡単に作れるようなものではない。
可能な人は数少なく、それを教えるのはとても難しい。

Eric Evans is one of those few who can create domain models well.
I discovered this by working with him — one of those wonderful times when you find a client who’s more skilled than you are.
Our collaboration was short but enormous fun.
Since then we’ve stayed in touch, and I’ve watched this book gestate slowly.

エリック・エバンスはよいドメインモデルを作れる数少ない一人だ。
私は、彼と一緒に働くことで発見した。（すばらしい時。あなたよりも、熟練したクライアントを見つけたとき。）
私たちのコラボレーションは短かったが、ものすごく大きな楽しみだった。
それから私たちは頻繁に連絡を取り合うようになり、私はこの本をゆっくりと温め、見守っていた。

It’s been well worth the wait.

待った甲斐があって、よい出来になった。

This book has evolved into one that satisfies a huge ambition:To descsribe and build a vocabulary about the very art of domain modeling.
To provide a frame of reference through which we can explain this activity as well as teach this hard-to-learn skill.
It’s a book that’s given me many new ideas as it has taken shape, and I’d be astonished if even old hands at conceptual modeling don’t get a raft of new ideas from reading this book.

この本は、大望を満たすまでに発展した。
それは、ドメインモデリングのとてもアートな部分を記述し、ボキャブラリーを構築することだ。
また、この学び難いスキルと同様に説明が難しいこの活動を通じて、フレームを提供することだ。
その本は、多くの新しい具体化した考えを私に与えてくれた。この本を読んで、私だけでなく、概念モデリングの熟練者でさえ驚かされた。

Eric also cements many of the things that we’ve learned over the years.
First, in domain modeling, you shouldn’t separate the concepts from the implementation.
An effective domain modeler can not only use a whiteboard with an accountant, but also write Java with a programmer.
Partly this is true because you cannot build a useful conceptual model without considering implementation issues.
But the primary reason why concepts and implementation belong together is this:
The greatest value of a domain model is that it provides a ubiquitous language that ties domain experts and technologists together.

エリックもまた、私たちが長年かけて学んできたたくさんのことを確固たるものにする。
最初に、ドメインモデリングでは、コンセプトと実装を分けるべきではない。
効果的なドメインモデラーは担当者とホワイトボードを使うだけではなくプログラマーとJava言語も書くことができる。
このことは、部分的には正しい。なぜなら、実装上の問題を考えないで、役立つ概念モデルを構築することはできないからだ。
しかし、概念と実装が同類のものである第一の理由はこれである。
ドメインモデルの最高の価値は、それ自身がユビキタス言語を提供し、それがドメイン・エキスパートとテクノロジストを結びつけることだ。

Another lesson you’ll learn from this book is that domain models aren’t first modeled and then implemented.
Like many people, I’ve come to reject the phased thinking of “design, then buld.”
But the lesson of Eric’s experience is that the really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.

他の教えでは、あなたはドメインモデルは初期モデルで実装されることはないことをこの本から学ぶでしょう。
大多数の人のように、私は「設計し、そして構築しなさい」という段階的な考えを拒絶するようになっている。
しかし、エリックの経験からくる教えは、長い時間をかけて、本当にパワフルなドメインモデルを考え出す。
そして、熟練したほとんどのモデラーでさえもが、システムの初期リリースの後に彼らの最良の考えを発見する。

I think, and hope, that this will be an enormously influential book.
One that will add structure and cohesion to a very slippery field while it teaches a lot of people how to use a valuable tool.
Domain models can have big consequences in controlling software development — in whatever language or environment they are implemented.

私はこの本が非常に影響の大きい本になると思う。そしてそうなることを望んでいる。
この本は、たくさんの人々に有効な手段を教えながら、とても不安定なフィールドに構造と凝集を追加していくだろう。
ドメインモデルはソフトウェア開発のコントロールにおいて、大きな結果をもたらすことができる。– どんな言語や環境、実装であっても。

One final yet important thought.
One of things I most respect abount this book is that Eric is not afraid to talk about the times when he hasn’t been successful.
Most authors like to maintain an air of disinterested omnipotence.
Eric makes it clear that like most of us, he’s tasted both success and disappointment.
The important things is that he can learn from both — and more important for us is that he can pass on his lessons

最後に、まだ重要なことがあります。
私がこの本についてもっとも尊敬することのひとつは、エリックが彼が失敗したときのことを話すことを恐れていないことだ。
ほとんどの作者は第三者的で全能的な空気を主張しがちだ。
エリックは彼は成功も失望も経験していて、それを私たちみんなにわかるように説明してくれる。
大事なことは、彼は成功と失望の両方から学んでいるということだ。そして、もっと重要なことは、彼自身が彼の経験を伝えているということだ。

Martin Fowler April2003

2003年4月　マーチンファウラー