ドメイン駆動設計の原則を体験的に学べるワークショップを開催します。(有料)
募集ページはこちら。
↓
実践的ドメイン駆動設計ワークショップ
このワークショップの意図と内容を紹介します。
ドメイン駆動設計の基本原則は、1章、2章、3章に集約されています。
■原則その1:ドメインの知識をかみ砕く
・ドメイン(そのアプリケーションの対象領域)に関する「知識」を継続的に学ぶ
・ドメインの「知識」を広げながら掘り下げ、より深く理解する
ドメインの知識の習得と理解は、どんな開発手法でも重要なテーマです。ドメイン駆動設計(あるいは、オブジェクト指向設計)では、コードを書く技術者が、自ら積極的にドメインの知識を学び続けることを重視します。
開発者が要件定義書や仕様書がでてくるのを待つのは、ドメイン駆動設計のアプローチではありません。
■原則その2:言葉を使って意図を伝達する
・利用者やその分野に専門家と「言葉」を使って、活発な意図の伝達(コミュニケーション)を行う
これは、XPなどのアジャイルな開発では、基本の活動です。
ウォータフォール式の開発では、要件定義や分析は「フェーズ」でした。その「フェーズ」の成果物を「ドキュメント」としてまとめ、次のフェーズで(要件定義者とは別の)技術者に渡されます。
ドメイン駆動設計はアジャイルなやり方が前提です。ドメイン駆動設計では、要件定義や分析は「フェーズ」ではありません。日々の「タスク」です。
要件定義の成果物として、他者に引き渡すためのドキュメントは必要ありません。開発者が自ら獲得した業務の知識・理解を、そのままコードに書きとめます。そうやって作った業務知識が豊富なソフトウェアを動かしながら、業務の経験者やプロダクトオーナと活発に会話をして、さらに詳細に仕様を決めていきます。
きれいにまとまった「ドキュメント」を作っても、関係者の間で、理解が食い違うことはよくあります。また、人間の作るものですので、ヌケモレや記述ミスがあちこちに潜んでいます。
なによりも問題なのは、ドキュメントをいくら作っても、それだけではソフトウェアは動かないことです。
不確実で役に立たない「ドキュメント」をせっせと作るよりも、関係者で会話して意図や仕様の詳細を確認したほうが、手っ取りばやいし、確実。つまり、費用対効果が高い。これが、XPで言葉を使った会話による意図伝達を重視する理由です。
■原則その3:モデルと実装を一致させる
開発者が、業務知識を増やし、プロダクトオーナーの意図を正確に理解したら、それをそのままコードで表現するのが、ドメイン駆動設計の重要な原則です。
開発者の業務知識の理解と、コード表現とは、ずれてしまうことが多い。
業務知識は、その業務固有の考え方ややり方に基づく知識であり、その分野の業務用語を使います。プログラムのソースコードは、どうしても、コンピュータの仕組みや、プログラミング言語や言語仕様に引っ張られます。
優秀な開発者であれば、頭の中の業務理解と、コンピュータよりのコード表現とを、無意識に変換できるかもしれません。
しかし、これは危険です。 業務の知識を表現できてないコードは、後になって、コード内容を理解したり、機能の追加や修正をやろうとした時に、意味が不明なコードだらけになりがちです。それが、ソフトウェアの変更コストをあげる大きな原因になります。
・どこになにが書いてあるかわからない
・業務的には単純なことが、プログラムのあちこちを修正しないと実現できない
・うっかり変更すると、わけのわからないところに影響がでた
...
こういうことを防ぐために、コード、特にドメイン層のプログラムは、業務知識、業務を理解した概念モデルを、そのままコードで表現することにこだわります。
これがドメイン駆動設計の基本原則です。
今回のワークショップは、このドメイン駆動設計の3原則を、チームで実際に体験しながら学習してみることを目的としています。
特に重視しているのが、次の3点です。
・「言葉」を使った意図の伝達
・「チーム」としてのアウトプットづくり
・タイムボックス(時間制限)
■「言葉」を使ったモデリングの体験学習
UMLやプログラミング言語ではなく「言葉」を使ってモデリングや設計するやり方を経験します。
UMLやプログラミング言語は、論理的な記述にはすぐれていますが、人間の「意図」の伝達や理解には、あまり向いていません。
人間が「意図」を伝える基本の道具はなんといっても「言葉」であり「会話」です。
アプリケーション、特にドメイン層の基本設計を、まず「言葉」を使ってモデリングしながら、コード表現に持っていく。あるいは、コード表現を説明しながら、モデルやコードの問題点を発見する。
このワークショップでは、この「言葉」と「コード」の双方向のいったりきたりを繰り返すことが、費用対効果の高いモデリングと設計の手段をあることを体験しながら学べます。
■「チーム」としてのアウトプットづくり
アプリケーション開発は、チーム活動です。
チームとしてゴールイメージを共有し、共同作業をして成果を生みだす活動です。
業務の理解、プロジェクトのゴールイメージ、設計の考え方は、プロジェクトの最初では、個人個人でばらばらです。そして、プロジェクトが進むにつれてチームとして学習しながら、しだいに共通理解を増やしながら、ソフトウエアプロダクトを成長させていきます。
このワークショップでは、見ず知らずの3人がチームになって、最初のばらばらの状態から、チームとして、共通理解を広げ、深めていく過程を、体験しながら学びます。
その時に「言葉」という道具の使い方の工夫と、その効果を実感することを狙ったさまざまなワークを行います。
■タイムボックス(時間制限)
すべてのワークは、15分とか、30分とかいう時間制限付で行います。
短い時間の中で、考え方も経験も異なる3人が、一つの結論を出すことは、とても困難です。
このワークショップでは、あえて短時間の制限をもうけることで、3人が難しい意思決定をすることを強制します。その限られた時間の中で、チームとしての成果を最大にするための、やり方や考え方のコツを体験しながら学びます。
この場合も、「言葉」を使った会話が重要な役割を演じます。
この内容に興味を持たれたかたは、ぜひ、ご参加ください。
ドメイン駆動設計の考え方を現場で役に立つ、さまざまなモデリングや設計のやり方を体験しながら、学べる機会です。
お申込み、お問合せはこちらから
↓
実践的ドメイン駆動設計ワークショップ
募集ページはこちら。
↓
実践的ドメイン駆動設計ワークショップ
このワークショップの意図と内容を紹介します。
ドメイン駆動設計の3原則
ドメイン駆動設計の基本原則は、1章、2章、3章に集約されています。
■原則その1:ドメインの知識をかみ砕く
・ドメイン(そのアプリケーションの対象領域)に関する「知識」を継続的に学ぶ
・ドメインの「知識」を広げながら掘り下げ、より深く理解する
ドメインの知識の習得と理解は、どんな開発手法でも重要なテーマです。ドメイン駆動設計(あるいは、オブジェクト指向設計)では、コードを書く技術者が、自ら積極的にドメインの知識を学び続けることを重視します。
開発者が要件定義書や仕様書がでてくるのを待つのは、ドメイン駆動設計のアプローチではありません。
■原則その2:言葉を使って意図を伝達する
・利用者やその分野に専門家と「言葉」を使って、活発な意図の伝達(コミュニケーション)を行う
これは、XPなどのアジャイルな開発では、基本の活動です。
ウォータフォール式の開発では、要件定義や分析は「フェーズ」でした。その「フェーズ」の成果物を「ドキュメント」としてまとめ、次のフェーズで(要件定義者とは別の)技術者に渡されます。
ドメイン駆動設計はアジャイルなやり方が前提です。ドメイン駆動設計では、要件定義や分析は「フェーズ」ではありません。日々の「タスク」です。
要件定義の成果物として、他者に引き渡すためのドキュメントは必要ありません。開発者が自ら獲得した業務の知識・理解を、そのままコードに書きとめます。そうやって作った業務知識が豊富なソフトウェアを動かしながら、業務の経験者やプロダクトオーナと活発に会話をして、さらに詳細に仕様を決めていきます。
きれいにまとまった「ドキュメント」を作っても、関係者の間で、理解が食い違うことはよくあります。また、人間の作るものですので、ヌケモレや記述ミスがあちこちに潜んでいます。
なによりも問題なのは、ドキュメントをいくら作っても、それだけではソフトウェアは動かないことです。
不確実で役に立たない「ドキュメント」をせっせと作るよりも、関係者で会話して意図や仕様の詳細を確認したほうが、手っ取りばやいし、確実。つまり、費用対効果が高い。これが、XPで言葉を使った会話による意図伝達を重視する理由です。
■原則その3:モデルと実装を一致させる
開発者が、業務知識を増やし、プロダクトオーナーの意図を正確に理解したら、それをそのままコードで表現するのが、ドメイン駆動設計の重要な原則です。
開発者の業務知識の理解と、コード表現とは、ずれてしまうことが多い。
業務知識は、その業務固有の考え方ややり方に基づく知識であり、その分野の業務用語を使います。プログラムのソースコードは、どうしても、コンピュータの仕組みや、プログラミング言語や言語仕様に引っ張られます。
優秀な開発者であれば、頭の中の業務理解と、コンピュータよりのコード表現とを、無意識に変換できるかもしれません。
しかし、これは危険です。 業務の知識を表現できてないコードは、後になって、コード内容を理解したり、機能の追加や修正をやろうとした時に、意味が不明なコードだらけになりがちです。それが、ソフトウェアの変更コストをあげる大きな原因になります。
・どこになにが書いてあるかわからない
・業務的には単純なことが、プログラムのあちこちを修正しないと実現できない
・うっかり変更すると、わけのわからないところに影響がでた
...
こういうことを防ぐために、コード、特にドメイン層のプログラムは、業務知識、業務を理解した概念モデルを、そのままコードで表現することにこだわります。
これがドメイン駆動設計の基本原則です。
ワークショップの内容
今回のワークショップは、このドメイン駆動設計の3原則を、チームで実際に体験しながら学習してみることを目的としています。
特に重視しているのが、次の3点です。
・「言葉」を使った意図の伝達
・「チーム」としてのアウトプットづくり
・タイムボックス(時間制限)
■「言葉」を使ったモデリングの体験学習
UMLやプログラミング言語ではなく「言葉」を使ってモデリングや設計するやり方を経験します。
UMLやプログラミング言語は、論理的な記述にはすぐれていますが、人間の「意図」の伝達や理解には、あまり向いていません。
人間が「意図」を伝える基本の道具はなんといっても「言葉」であり「会話」です。
アプリケーション、特にドメイン層の基本設計を、まず「言葉」を使ってモデリングしながら、コード表現に持っていく。あるいは、コード表現を説明しながら、モデルやコードの問題点を発見する。
このワークショップでは、この「言葉」と「コード」の双方向のいったりきたりを繰り返すことが、費用対効果の高いモデリングと設計の手段をあることを体験しながら学べます。
■「チーム」としてのアウトプットづくり
アプリケーション開発は、チーム活動です。
チームとしてゴールイメージを共有し、共同作業をして成果を生みだす活動です。
業務の理解、プロジェクトのゴールイメージ、設計の考え方は、プロジェクトの最初では、個人個人でばらばらです。そして、プロジェクトが進むにつれてチームとして学習しながら、しだいに共通理解を増やしながら、ソフトウエアプロダクトを成長させていきます。
このワークショップでは、見ず知らずの3人がチームになって、最初のばらばらの状態から、チームとして、共通理解を広げ、深めていく過程を、体験しながら学びます。
その時に「言葉」という道具の使い方の工夫と、その効果を実感することを狙ったさまざまなワークを行います。
■タイムボックス(時間制限)
すべてのワークは、15分とか、30分とかいう時間制限付で行います。
短い時間の中で、考え方も経験も異なる3人が、一つの結論を出すことは、とても困難です。
このワークショップでは、あえて短時間の制限をもうけることで、3人が難しい意思決定をすることを強制します。その限られた時間の中で、チームとしての成果を最大にするための、やり方や考え方のコツを体験しながら学びます。
この場合も、「言葉」を使った会話が重要な役割を演じます。
ぜひご参加を
この内容に興味を持たれたかたは、ぜひ、ご参加ください。
ドメイン駆動設計の考え方を現場で役に立つ、さまざまなモデリングや設計のやり方を体験しながら、学べる機会です。
お申込み、お問合せはこちらから
↓
実践的ドメイン駆動設計ワークショップ