ドキュメント作成は退屈な作業だ。疎かにされたり，誤った扱いをされることも少なくない。しかしCyrille Martraire氏は，今年ロンドンで開催されたDDD Exchangeカンファレンスでのプレゼンテーションで，ドキュメントとコードをともに改良する新たな考え方として，ドメイン駆動開発(DDD)を使って“生きたドキュメント(living documentaion)”を作る方法を紹介した。
Martraire氏の考えるドキュメントの目的とは，将来のための，場合によっては規約遵守のための，知識の継承に他ならない。DDDとはドメインの知識である。この知識獲得の例として，ドメインを理解する効果的な方法と氏が考えるのがイベントストーミングだ。氏はまた，振る舞いをドキュメント化する方法として，対話とシナリオの具体例を使った振る舞い駆動開発(BDD)の利用を推奨する。Cucumberなどのツールを使えば，シナリオをコードと対照しながら実行することが可能になる。コードと常に同期する，“生きたドキュメント”の代表的な例だ。
DDDの観点からコードを見れば，コンテキスト境界(bounded context)が，暗黙的ではあるが，すでに存在しているのが分かる。パッケージやネームスペースをアノテーションすることで，さまざまなコンテキストを，これもコードと常に同期した方法で，ドキュメントとして宣言し記述することが可能になる。その副次的効果として，氏が大きな価値を認めるのは，このテクニックが，氏が“埋め込み型学習(embedded learning)”と呼んでいる，別のDDD概念をも可能にすることだ。
コードやクラス，インターフェース，メソッド，ドメイン関連のさまざまな宣言といったものが，すでにユビキタスな言語に存在しているのと同じように，コードのアノテーションを検索して最新の用語集を生成することによって“生きた用語集”を作ることが可能になる。氏の以前のプロジェクトでは，この方法で作成した用語集を定期的にプロジェクトオーナに提出することで，大きな成功を収めることができた。
設計の文書化の例としてMartraire氏が用いたのは，ドメインモデルのみを内部に配置し，他はすべて外部に置くというヘキサゴナルアーキテクチャである。このパターンはすでに文書化されていて，コード内のパターンに慎重に従うことで，そのデザインが暗黙的にコードに収められていることを確認できる，と氏は考える。パッケージやネームスペースにアノテーションを使用さえすれば，先程述べたのと同じような方法で，コードに対応した“生きたダイアグラム”を作ることが可能になる。
これらのテクニックから氏は，もうひとつの大きな価値を見出している。それは，もし“生きた用語集”などのドキュメントを作ることが難しいと感じるならば，DDDを誤った方法で行っているというシグナルであり，コードの現実を再確認し，ドキュメントによってコードを改善する必要がある，ということだ。
Martraire氏は現在，“Living Documentaion”という書籍を執筆中で，Leanpubでの公開を予定している。
来年のDDD Exchangeは2016年6月10日の予定で，すでに登録を開始している。