Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
設計の話をする前にすり合わせしたい言葉 / Reconcile our word before start designing architecture
Search
ShinkuFencer
January 10, 2019
Technology
1
1.6k
設計の話をする前にすり合わせしたい言葉 / Reconcile our word before start designing architecture
App Client Melting Pot #1「設計」
https://app-client-mp.connpass.com/event/112973/
にて飛び込みLTした資料です。
ShinkuFencer
January 10, 2019
Tweet
Share
More Decks by ShinkuFencer
See All by ShinkuFencer
オブジェクト指向CSSが叶えたかったことと、CSSのいま / The aims of Object-oriented CSS and the current state of CSS usage
shinkufencer
12
4.5k
無用な認知負荷を減らしてお手入れしやすいコードを書こう / Reduce unnecessary cognitive load and write maintainable code
shinkufencer
0
4.5k
DDD関連のフレーズから入るざっくりDDD超入門 / Roughly DDD Learn,Starting with DDD-related Phrases
shinkufencer
1
520
書くときにひと呼吸おいて考えてから 書いてほしいRailsコードの書き方 / Rails programing code that I hope you will consider if you really need it
shinkufencer
0
1.8k
とりあえず抑えておきたい Railsでの「テストの内容」の考えかた #kaigionrails /Test code concepts to keep in mind for now with Rails
shinkufencer
4
1.5k
before_actionとのつらくならない付き合い方 #kaigionrails / how to using "before_action" with happy in Rails
shinkufencer
5
5.2k
テストコード未経験者が RailsでそれなりにRSpecがかけるようになるまでの話 /Inexperience Rails developer ,Use Rspec
shinkufencer
2
1.1k
セイチョウのための一歩 ブログ習慣化のあゆみ
shinkufencer
1
1.6k
Other Decks in Technology
See All in Technology
転移学習とドメイン適応の基礎
kmatsui
2
580
KubeCon EU 2024 Recap “Kubernetes Policy Time Machine: Where to Next?”
ryysud
0
140
反実仮想機械学習とは何か
usaito
PRO
7
2.5k
Janus
bkuhlmann
1
490
マルチアカウント環境への発見的統制の導入
ch1aki
1
1.3k
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
200
最近たまに見かけるTiDBってなんだ? - Findy
pingcap0315
2
630
Google Cloud の AI を支える裏側のインフラを垣間見る!
maroon1st
0
210
Aurora MySQL v3(MySQL8.0互換)の オンラインDDLの罠挙動を全バージョンで検証した
yutakikai
1
150
Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing Recap
koh_naga
0
150
現代CSSフレームワークの内部実装とその仕組み
poteboy
6
2k
ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない
saramune
0
100
Featured
See All Featured
Being A Developer After 40
akosma
56
580k
Stop Working from a Prison Cell
hatefulcrawdad
266
19k
Designing Experiences People Love
moore
136
23k
StorybookのUI Testing Handbookを読んだ
zakiyama
11
4.6k
Debugging Ruby Performance
tmm1
70
11k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
19
1.9k
Code Reviewing Like a Champion
maltzj
513
39k
Web development in the modern age
philhawksworth
202
10k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
6
990
It's Worth the Effort
3n
180
27k
Transcript
設計の話をする前に すりあわせをしたい言葉 App Client Melting Pot #1 飛び込みLT枠
しんくう 最近はRailsエンジニア 過去を振り返ると PHPやったり Android開発したり Unityでアプリ作ったり 浅く広くいろいろやってきました Twitter : @shinkufencer
2 自己紹介
3 自己紹介 Webアプリケーション開発者から見た、 MVCとMVP、そしてMVVMの違い - Qiita https://qiita.com/shinkuFencer/items/f2651073fb71416b6cd7
設計に関して理解が深まって 「メンバーのみんなと知識を共 有しよう!」 と言う前にすり合わせておくと いいかもしれない言葉を 雑にあげてみました 4
意味をすりあわせしたい言葉 5
ドメイン 6
• 「ドメイン」という言葉、人によって受け取 り方が違う • 設計の場で語られるのはドメイン駆動設計で 使われるドメイン • domainという言葉が由来であるはずだが、 言葉そのもの意味はあまり説明されていない •
日本語としてはURLのドメインを連想する人 もいる(気がする)(体験談) 7 ドメイン
• 説明例としては以下 8 ドメイン “ドメインとは、広い意味でいうと、組織が 行う事業やそれを取り巻く世界のことだ。事 業が市場を定義して、プロダクトやサービス を販売する。組織にはそれぞれ、自分たちの 対象とする領域についてのノウハウや物事の 進めかたがある。その領域、そして業務を進
めていくための方法がドメインだ。” 実践ドメイン駆動設計 第2章の冒頭より引用
• ドメインという言葉はすっと入りづらい言葉 • さっきの回答例通りいくと「業務」や「サー ビス」の主たる部分のことを指すのでそのよ うな形で言葉のありかたの共通認識をとると 良さそう 9 ドメイン
モデル(Model) 10
• 日本語としても意味が複数ある言葉なのでま ずそこで認識の土台が変わる • Modelと認識できても細かい部分は三者三様 ◦ 特定のクラスの役割を意味するものと勘違いするこ とがある極端な例だけど、Ruby on Railsだけやって
きたひとだとActiveRecord = Model という勘違い ◦ JSONとHashだけで終わる世界観だとモデルという 観点を考えない場面もある • 設計などにおいては「データのモデル」とい う側面で使われるのでデータモデリングとい う言葉で考えると良さそう 11 モデル(Model)
• 説明例としては以下 12 モデル(Model) “組織内での意思疎通を改善し、それによってよ り柔軟で安定したアプリケーション環境に導く、 真の情報の部分集合を正確に説明するシンボ ルとテキストの集合を使う、事業とIT専門家の両 方のための、道筋を見つける道具である” Wikipediaのデータモデルのページより引用
• これもドメイン同様に日本語で端的に表現し にくい言葉 • モデリングすることについても「広義の意味 だとこうだけど、この開発においては◯◯だ よね、みたいで話しておくと良いかもしれな い」 13 モデル(Model)
使うことによるメリットを すりあわせたい言葉 14
レイヤード アーキテクチャ 15
• 責務ごとに レイヤーに分けて作る アーキテクチャ • 例示としてよくでてくる のは横の4つのレイヤー ◦ ヘキサゴナル、オニオン クリーン、いずれも
基本はこの概念の発展形 16 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー
• 分けるメリット ◦ 関心事の分離ができる ◦ 隣り合う層同士は依存するが 離れたところは分離可 17 レイヤードアーキテクチャ UIレイヤー
Applicationレイヤー Domainレイヤー Infrastructureレイヤー 関心ごとの分離をして 疎な状態に保ってあげることで レイヤードアーキテクチャの メリットを得ることができる
• 無意識にメリットが損なわれるケース 18 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー ユーザの年齢と名前 を表示したい
保存領域には JSONで保存
• 無意識にメリットが損なわれるケース 19 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSONから変換するほど でもないから
JSONのStringを UIレイヤーまで そのままリレーして 変換して使おう JSON
• 無意識にメリットが損なわれるケース 20 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSON JSON
JSON JSON ちゃんと各レイヤーごとに 渡しているから分離してるし 簡便にデータを渡せてるよね!
• 無意識にメリットが損なわれるケース 21 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSON JSON
JSON JSON 言葉通りにはしている 気がするが なにか違う気がする…
• 実質こうなってしまっている 22 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー JSON JSON
• 疎じゃなくなってる ◦ そのままのリレーだと UIレイヤーが隣り合わない Infraレイヤーの情報を そのままつかっていることに ◦ 右図のように UIが2つのレイヤーに
依存する形になってしまう ◦ 疎にするなら、JSONをまま ではなく、JSON形式の違う データとしてリレーすると 問題はなくなる(はず) 23 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー
• 言葉通りにやってみたが 実際はメリットが得られて いない • 設計の用語は さらりと概念だけなぞると 本質的な部分の把握が 抜け落ちがち ちゃんとすり合わせながら
つかっていきたい 24 レイヤードアーキテクチャ UIレイヤー Applicationレイヤー Domainレイヤー Infrastructureレイヤー
• 設計に使われるドメイン、モデル、割と日本 語由来ではない表現や複数の意味を持つ言葉 は認識がブレるので意識合わせが大切 • 言葉でメリットを理解しても、無意識にメ リットを享受できてない使い方をしてしまう ことがあるので、言葉と実体験を交えながら すり合わせられるとハッピーかも 25
まとめ
ありがとうございました 26