先月から，フルスクラッチでサーバアプリケーションの開発に携わることになり，設計に関して悶々と格闘している日々です．
その中で，リーダーの紹介で，DDDに興味を持ち始めました．DDDは，ある一つの設計思想ですが，アジャイル開発を前提としている概念です．
今回は，アジャイル開発を実践していることを踏まえ，DDDの基本パターンから感じた事を書きます．
Domain-driven design ドメイン駆動設計とは
ソフトウェアの設計手法であり，'複雑なドメインの設計はモデルベースで行うべきであり'，'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする（Wikipediaより）つまり，図にするとこういうことです．
開発工程を進める中で，ドメインモデルが開発の中心にあり，ドメインモデルによって開発が駆動していくということです．
各工程で，プロダクトコードとコミュニケーションが常にドメインモデルとリンクし，ドメインモデルがブラッシュアップされていくイメージです．
DDDの基本となる３パターン
- Ubiquitous Language（ユビキタス言語）パターン
- Model-Driven Design（モデル駆動設計）パターン
- Hands-On Modeler（実践的モデラー）パターン
ドメインモデルを機能させるための基本パターンで，要は，ユビキタス言語を用いてドメインモデルが構築され，開発者がそれを理解しているモデラーかつプログラマであることを目標としています．
このパターンの中で，ユビキタス言語パターンが特に重要だと感じています．
ドメインを正しく捉えた柔軟で価値の高いソフトウェアを設計するには，チームの共通言語を創造しなければならない．共通言語はユーザ，ドメインの専門家から，設計者，プログラマまで，分析／設計モデルからプログラムコードに至るまで，プロジェクトのすべての関係者，成果物に行き渡っていて，同じ意味で理解されるようなユビキタス（遍在的）な言語である．ドメインモデルがユビキタス言語となるようにし，ドメインモデルを介してプロジェクトが一体となるようにする．（[ 技術講座 ] Domain-Driven Designのエッセンス 第1回より）ユビキタス言語パターンは，プロジェクトに関係する「**モノすべて」**が，共通の「**言語**」で理解されることです．
「モノすべて」は，PO，SM，企画者，設計者，プログラマ，デザイナーを始め，顧客を含むヒト．それに加え，プログラムコードやドキュメントも含まれています．
これも図にしてみました．
プロジェクトが遅延に，この概念が関わっていることを実感しました．
認識の違いによる手戻り
プロジェクトの遅延原因が様々ですが，「**いつの間にか認識が違ったままプロジェクトが進んでいる**」ということが往々にしてあると実感しました．職種間で専門用語が異なるという状況で，「プログラマがPO向けにスプリントレビューをする際に，POがわかる用語で説明する」というように，異なる職種間では，よく考慮されています．
しかし，ユビキタス言語を用いて，特に認識を統一するべきなのなのは，開発チーム内でのやりとりだと感じます．
同じ専門用語を用いているはずなのに，認識が異なったまま，プロジェクトが進行していて，スプリント終盤になったら認識が違っていた，なんてことが実際に起こりました．
社内（チーム） vs 社外（顧客），開発チーム vs PO，開発者 vs 開発者，あらゆるところに認識の違いが生じることは，特に気をつける必要があります．
以前は，スプリント計画になんでそんなに時間をかけるんだ？と疑問でしたが，不明点をなくし，認識を統一するのに時間が必要と考えるようになりました．
まとめ
今回は，ユビキタス言語パターンを中心に書きました．アジャイル開発に対する誤解の一つとして「ドキュメントを作成しない」というのがあります．作成コストを意識して，価値のあるドキュメントだけを作成するというのが，誤解に対する回答としてよく言われていますが，
認識の差がうまれそうな物事に関しては，価値のあるドキュメントとして作成の優先度を挙げるべきだと感じました．
設計に関しては，実践しながら試行錯誤が続きますが，DDDの大元であるオブジェクト指向に関して，改めてキャッチアップしていこうと思います．