Domain Driven Design ■The Challenge of Complexity

ファウラー氏が絶賛するDDDの著者Eric EvansさんのサイトDDDの記事を訳します。
http://domaindrivendesign.org/

Domain-Driven Design: Tackling Complexity in the Heart of Software

複雑さへの挑戦

of course many things can put a project off course, bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features.

当然ながら、プロジェクトを目的からそらす要因は沢山あります。官僚機構、はっきりしない目的、リソースの欠如、２〜３の添え名、しかし、どのぐらいソフトウェアが複雑になる得るかを主に決定するのは、デザインするための方法論です。複雑さが手に負えなくなったら、ソフトウェアは、もはや簡単に変更することや拡張することのために十分理解することができません。それに反してよい設計は、それらの複雑な特徴を取り除く機会を作り出せます。

Some of these design factors are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.

設計事項の幾つかは、テクニカルなものです、そして取り組みの大部分は、ネットワークのデザイン、データベースのデザインや、他のソフトウェアの技術的要因です。
多くの本が、どうやってそれらの問題を解くかを記述しています。開発者は、洗練されたスキルを持っています。

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.

けれども、多くのアプリケーションでもっとも重要な複雑さは、テクニカルなものではありません。活動やユーザーのビジネスのドメインそのものにあります。
このドメインの複雑さは、設計のなかで取り扱われません。それはよく考えられたインフラストラクチャテクノロジーも問題になりません。成功した設計は、ソフトウェアのアスペクトの中心は、自動的に処理するべきです。