設計の話をする前にすり合わせしたい言葉 / Reconcile our word before start designing architecture

Transcript

1. 設計の話をする前に すりあわせをしたい言葉 App Client Melting Pot #1 飛び込みLT枠

2. しんくう 最近はRailsエンジニア 過去を振り返ると PHPやったり Android開発したり Unityでアプリ作ったり 浅く広くいろいろやってきました Twitter : @shinkufencer

   2 自己紹介

3. 3 自己紹介 Webアプリケーション開発者から見た、 MVCとMVP、そしてMVVMの違い - Qiita https://qiita.com/shinkuFencer/items/f2651073fb71416b6cd7

4. 設計に関して理解が深まって 「メンバーのみんなと知識を共 有しよう！」 と言う前にすり合わせておくと いいかもしれない言葉を 雑にあげてみました 4

5. 意味をすりあわせしたい言葉 5

6. ドメイン 6

7. • 「ドメイン」という言葉、人によって受け取 り方が違う • 設計の場で語られるのはドメイン駆動設計で 使われるドメイン • domainという言葉が由来であるはずだが、 言葉そのもの意味はあまり説明されていない •

   日本語としてはURLのドメインを連想する人 もいる（気がする）（体験談） 7 ドメイン

8. • 説明例としては以下 8 ドメイン “ドメインとは、広い意味でいうと、組織が 行う事業やそれを取り巻く世界のことだ。事 業が市場を定義して、プロダクトやサービス を販売する。組織にはそれぞれ、自分たちの 対象とする領域についてのノウハウや物事の 進めかたがある。その領域、そして業務を進

   めていくための方法がドメインだ。” 実践ドメイン駆動設計 第2章の冒頭より引用

9. • ドメインという言葉はすっと入りづらい言葉 • さっきの回答例通りいくと「業務」や「サー ビス」の主たる部分のことを指すのでそのよ うな形で言葉のありかたの共通認識をとると 良さそう 9 ドメイン

10. モデル(Model) 10

11. • 日本語としても意味が複数ある言葉なのでま ずそこで認識の土台が変わる • Modelと認識できても細かい部分は三者三様 ◦ 特定のクラスの役割を意味するものと勘違いするこ とがある極端な例だけど、Ruby on Railsだけやって

    きたひとだとActiveRecord = Model という勘違い ◦ JSONとHashだけで終わる世界観だとモデルという 観点を考えない場面もある • 設計などにおいては「データのモデル」とい う側面で使われるのでデータモデリングとい う言葉で考えると良さそう 11 モデル（Model）

12. • 説明例としては以下 12 モデル（Model） “組織内での意思疎通を改善し、それによってよ り柔軟で安定したアプリケーション環境に導く、 真の情報の部分集合を正確に説明するシンボ ルとテキストの集合を使う、事業とIT専門家の両 方のための、道筋を見つける道具である” Wikipediaのデータモデルのページより引用

13. • これもドメイン同様に日本語で端的に表現し にくい言葉 • モデリングすることについても「広義の意味 だとこうだけど、この開発においては◯◯だ よね、みたいで話しておくと良いかもしれな い」 13 モデル（Model）

14. 使うことによるメリットを すりあわせたい言葉 14

15. レイヤード アーキテクチャ 15

16. • 責務ごとに レイヤーに分けて作る アーキテクチャ • 例示としてよくでてくる のは横の4つのレイヤー ◦ ヘキサゴナル、オニオン クリーン、いずれも

    基本はこの概念の発展形 16 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー

17. • 分けるメリット ◦ 関心事の分離ができる ◦ 隣り合う層同士は依存するが 離れたところは分離可 17 レイヤードアーキテクチャ UIレイヤー

    Applicationレイヤー Domainレイヤー Infrastructureレイヤー 関心ごとの分離をして 疎な状態に保ってあげることで レイヤードアーキテクチャの メリットを得ることができる

18. • 無意識にメリットが損なわれるケース 18 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー ユーザの年齢と名前 を表示したい

    保存領域には JSONで保存

19. • 無意識にメリットが損なわれるケース 19 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSONから変換するほど でもないから

    JSONのStringを UIレイヤーまで そのままリレーして 変換して使おう JSON

20. • 無意識にメリットが損なわれるケース 20 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSON JSON

    JSON JSON ちゃんと各レイヤーごとに 渡しているから分離してるし 簡便にデータを渡せてるよね！

21. • 無意識にメリットが損なわれるケース 21 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSON JSON

    JSON JSON 言葉通りにはしている 気がするが なにか違う気がする…

22. • 実質こうなってしまっている 22 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSON JSON

23. • 疎じゃなくなってる ◦ そのままのリレーだと UIレイヤーが隣り合わない Infraレイヤーの情報を そのままつかっていることに ◦ 右図のように UIが2つのレイヤーに

    依存する形になってしまう ◦ 疎にするなら、JSONをまま ではなく、JSON形式の違う データとしてリレーすると 問題はなくなる（はず） 23 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー

24. • 言葉通りにやってみたが 実際はメリットが得られて いない • 設計の用語は さらりと概念だけなぞると 本質的な部分の把握が 抜け落ちがち ちゃんとすり合わせながら

    つかっていきたい 24 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー

25. • 設計に使われるドメイン、モデル、割と日本 語由来ではない表現や複数の意味を持つ言葉 は認識がブレるので意識合わせが大切 • 言葉でメリットを理解しても、無意識にメ リットを享受できてない使い方をしてしまう ことがあるので、言葉と実体験を交えながら すり合わせられるとハッピーかも 25

    まとめ

26. ありがとうございました 26