Skip to content

vol7_20140601

Jump to bottom Edit New page
@kuma_nana edited this page Jun 24, 2014 · 18 revisions

第７回ドメイン駆動設計読書会@大阪

目次

概要

  • 日時：2014/06/01 14:00 - 17:00
  • 場所：市民交流センターなにわ 103号室
  • 範囲：第2部 モデル駆動設計の構成要素 - 第４章 ドメインを隔離する
  • 方法：数分間黙読後、グループでディスカッション

グループ1の議論

  • レポート担当：@smori1983
  • 発表：@smori1983

第2部 モデル駆動設計の構成要素

p.63 モデル駆動設計を構成する言語のナビゲーションマップ

これらの標準パターンを共有することで、

  • 設計に秩序がもたらされ、
  • チームメンバが互いの仕事を理解しやくすなり、
  • ユビキタス言語も成長する。

第４章では、ドメインを隔離するのに使用する「レイヤ化アーキテクチャ」について議論される。

第4章 ドメインを隔離する

レイヤ化アーキテクチャ

ソフトウェアプログラムには、様々な種類のタスクを実行する設計とコードがある。

  • ユーザ入力を受け付け、
  • ビジネスロジックを実行し、
  • データベースにアクセスして、
  • ネットワークを通じて通信し、
  • ユーザに情報を表示する

ドメイン関連のコードが他のコードの中に拡散すると、コードを見て意味を理解するのがきわめて困難になる。

  • 関心事を分離し、それぞれの要素に集中しつつ、
  • 分離された要素間の相互作用を引き続き維持する

ために、レイヤ化アーキテクチャが採用される。

  • レイヤ内のどの要素も、同じレイヤの他の要素か、その下にあるレイヤの要素にしか依存しない
  • 上方レイヤへのコミュニケーションは、何らかの間接的な仕組みを介する

という基本原則に従う。

おおよそ以下の4層を基本的な概念的レイヤとして採用する。

  • ユーザーインタフェース
  • アプリケーション層
  • ドメイン層
  • インフラストラクチャ層

モデル駆動設計にとって重要なのは、ドメイン層を分離することであり、 表示や格納、アプリケーションタスク管理などの責務から解放されることで、 ドメインオブジェクトはドメインモデルを表現するという責務に専念できる。

ドメイン層の中身

ドメイン層には、

  • エンティティ
  • プロセス（手続き）を扱うオブジェクト
  • 制約（ルール）を扱うオブジェクト

などが含まれ、すべてが永続化対象というわけではない。

ドメイン層の他レイヤへの現れ方

  • モデルが主としてまずあって、

    • 「保存形式」としてのインフラストラクチャ層（データベース）
    • 「投影形式」としてのユーザインターフェイス（ドメインモデルのスナップショットを提供する）

  • DSLの文脈

※ファウラーの言語ワークベンチ http://capsctrl.que.jp/kdmsnr/wiki/bliki/?LanguageWorkbench

インフラストラクチャ層の位置付け
  • その他諸々が集められる・・
  • インフラストラクチャ層の中にも、いろいろな責務の対象がある。

レイヤを関係づける

  • 分離されたレイヤ同士は、結局はつながっていなければならないが、 設計の依存関係は1方向にだけ向けるということが基本原則となる。
  • ドメインオブジェクトの設計の際、ユーザインタフェースを考慮しないようにすべきで、 それが可能であればどのようなアプローチ（MVC等）でもかまわない。
  • インフラストラクチャ層は技術的な機能の多くを「サービス」として提供する。 それらが何を提供するかのみを知ればよく、どのように行うかはカプセル化されるべきである。

アーキテクチャフレームワーク

通常、何らかのかたちのアーキテクチャフレームワークが必要であるが、

  • 重要な問題を解決するためにドメインモデルを表現し、
  • そのモデルを使用する実装を構築するという目標に集中しなければならない。

そのためには、

  • 必ずしもフレームワークのすべての機能を使用する必要はなく、
  • アプリケーションの技術的側面を解決するために必要なものだけを選んで適用すればよい。

実際には、

  • 「この言語を使ってみたい」という希望
  • 昔から使っている
  • 経験者が多い

等々の理由による、言語・フレームワーク選択もある。。

ドメイン層はモデルが息づく場所

ドメイン駆動設計がレイヤ化アーキテクチャに求めるものは、たったひとつの特別なレイヤ（ドメイン層）が存在すること。

  • プログラムの他の関心事から隔離され、
  • モデルと、モデルに直接関係する設計上のすべての要素が現れる場所を確保する。

利口なUI「アンチパターン」

その他の隔離

結局、ドメインを隔離することの最も優れた点は、それ以外のものをすべて取り払って、ドメインの設計に本当に集中できるようにすることにあるのだ。

全体的な議論

なにが「ドメイン」かをどう決めるか（どう決まるか）

設計そのものについて

  • あるコンテキストが定まらないと、ある意味設計はできない。
  • 色んなオブジェクトをあるコンテキストに置き、使い方を決める、構成を決める。
  • 色んなユースケースに対応するにあたり、個々のコンポーネントは、そのコンテキストにより使用するかしないかが判断される。
「Domain」というディレクトリ名によって、ドメインレイヤーを固定する、という実装方法は、
学習用の例としては分かりやすいのだけれども、システム設計として見た時に、本質的ではない。

例えば、大きなシステムの内に、サブプロジェクトAと、サブプロジェクトBがあるとして、
サブプロジェクトAのDomain、BのDomain、というようにディレクトリ名を作っていくとすると、
汎用的な「Domain」ディレクトリがもしあったら、そこらじゅうにその「Domain」があふれて存在することになる。

もしサブプロジェクトAの「Domain」が、Aからしか使うことができない、とすると、再利用性が失われてしまうことになる。

個々のコンポーネントが、いろいろなグルーピングによって、使われたり、使われなかったりすることにより、
コンポーネントの再利用と、さまざまなユースケースへのシステムの対応とが実現できる。

「Domain」というディレクトリ名にするのではなく、普通のライブラリと同じように、適切に名前空間を付けるだけで良いのでは。
そのただの名前空間も、実際にはもちろんドメイン層ではあるのだけれども。

#グループ２の議論

  • 司会：nomiさん　　　
  • 書記：fukanoya

電子版しか保有してないためページ数は記載しておりません

##第２部　モデル駆動設計の要素 ここでは、主にkawakawaさんの質問が主な議題になって行われる。

####［Q］1.ドメイン駆動設計は、伝統的ないくつかの考え方を基に、強調する点をずらしているのだ。 とありますが、強調する点をずらしているとは何を意味するのだろう

  • 議論内容 * オブジェクト指向は大切だが、ドメインを意識することが大切である。　　　 * ユビキタス言語の語彙に使う。オブジェクト指向だけ作ろうとしてるわけでない。
* ユビキタス言語を重要視する設計手法ではないか   
* 単純にドメインモデルに集中する。この本ではやりたいコンテキストに集中している。   
  * →抽象的でわかりにくい。

* モデリングの仕方を期待してはいっている本ではない。コミュニケーションやプロセスを語っている。

 * →DDD本は、プロセスに集中している。モデリングの手法の解説書ではない。
 * →チームやプロセス、コミュニケーションについて語っている。
 * →後半はプロジェクトのあるある集だよ　３部、４部。

####2.折衷案とは

［Q］「それによって道を外れることなく、折衷案を考え出すことができるのだ」という意味は？

  • ドメインエキスパートが描く分析モデルと開発者が実装する実装モデルの間にドメインモデルがある。それらの折衷案である。

##第４章　ドメインを隔離する ###レイヤー化アーキテクチャ

［Q］図で差すUI層からインフラ層へ指す矢印の意味は何ですか？

* 継承の矢印ではないか？
* 矢印の表記はいくつかあるが全てレイヤー間の参照をあらわしているのでは?
* 理想はUIからインフラ層へ直接参照しない
* →想像の域を脱せず回答はみつからなかった

  • レイヤー図のインフラ層は「ドメインの永続化を行うものを差すのではない。４層間における相互作用のパターンもアーキテクチャフレームワークを通じてサポートする」

  • ドメインを分離していると、クラウドに移植する場合も移植性が高いのではないか

[Q]アプリケーション層とは何ですか　イメージがつきません？

*例えば、バッチの切り替え呼び出し
*ＶＢのコマンドやstrutsのアクションにあてはまるのではないか
* サービスレイヤーはドメイン層ではない
* オブジェクト指向のサービスはドメイン層へのサービスである

４つのレイヤーの中にもそれぞれのサービスがある
* ＵＩ/アプリケーション/ドメイン層にサービスがある。書籍の後半ででてきます。（らしい）

###４．１．－オンラインバンキングの機能をレイヤーに分割する [Q]シーケンス図の引き落とし失敗処理がなぜドメイン層でないのはなぜか

  • この場合はシステムの都合によって決まっているため。ドメイン(業務や関心事の知識や活動領域）ではないためである。
  • トランザクションの単位は難しい。
  • ドメイン層にとって抽象化することは、目的を決めることが大事。
  • →目的がないと汎用的になってしまい

クライアントＭＶＣの課題

  • クライアントMVCの議論がでましたが、ここはメモできてないので一部割愛。

  • 必要に応じて問題なければクライアントＭＶＣにドメインを持たせて処理をさせていい。

  • 物理的なドメインと論理的なドメインはずれてくる。

  • ＵＩにどれだけドメイン層とデータを持たせるかがポイント

  • コンテキストはドメインできれいに分かれる必要はない

  • テクニカルなアーキテクチャのドメインとＤＤＤのドメインを分ける必要があるのか?

  • →クライアントとサーバーではなくドメイン層というレイヤーでとらえればよい。

    コアコンピタンスはひとつしかない。そこに注力しよう。

###利口なＵＩ [Q]おおがかりなプロジェクトの大がかりとは何か？人、開発規模、複雑さ？

1.ドメインロジックが複雑でドメインエキスパートを協力しないといけないようなもの 2.システムのライフサイクルが長いもの=> ドメインの寿命は長い。 この夏だけのシステムとかなら、おおがかりとはいわない。

####[Q]トランザクションスクリプトについては、あまり納得していないがエバンスはどう思っているか？

  • ここでは利口なＵＩとトランザクションスクリプトの構成の説明がありました。

利口なＵＩ

  • ＵＩ=>ドメイン、インフラ
  • 例えばＦｏｒｍにドメインロジックがあり永続化の責務があてられている

トランザクションスクリプト

  • ＵＩ=>アプリケーション=>ドメイン、インフラ
  • 業務ロジックがActionにつらつらと書かれているベストでないがまだよい。

ＤＤＤ

  • UI=>アプリケーション=>ドメイン=>インフラ

  • ＤＤＤ本とあわせてエンタープライズアプリケーションアーキテクチャを読むと理解が深まります。

###■発表後の久保さんからの指摘

  • レイヤー化アーキテクチャの図は上から下に表現されているがフラット（横倒し）にして捕らえると理解しやすい。　ドメインに集中するために、レイヤーを分けていることを意識する。

##編集後記

  • おつかれさまです。　アップが遅くなってすいません。 *第一部に比べて、あれを乗り越えてきたので理解や議論が活発になってきています。

  • 毎回話題にあがるのですが、モデリング（この場合ＵＭＬ）の手法を求めてはいけないと思います。これまでの経験を置いといて、こういう考えもあるのだと素直な気持ちで読むことが大事だと思います。

  • JJUG ナイトセミナー 「6.11 ドメイン駆動設計特集！ 」がありました。 tweeterで流れていたものでよかったものを連携します。

    • 用語はあくまで記号なので、その用語を使う文脈を共有しないと共通の理解が得られない #jjug_ddd

    • ユーザが理解出来ないモデルはモデルではない #jjug_ddd

    • 和智さん曰く、第１部を読んだ後に、第２部を読むと挫折するので、おすすめは先に第３部を読むことだそうです #jjug_ddd　（！＿！）これは！

  • windowsのおすすめMarkDowneエディタを教えてください。

###以上

Add a custom footer
Add a custom sidebar
Clone this wiki locally