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...
Search
ShinkuFencer
January 10, 2019
Technology
1
1.8k
設計の話をする前にすり合わせしたい言葉 / 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
13
5.5k
無用な認知負荷を減らしてお手入れしやすいコードを書こう / Reduce unnecessary cognitive load and write maintainable code
shinkufencer
0
5.7k
DDD関連のフレーズから入るざっくりDDD超入門 / Roughly DDD Learn,Starting with DDD-related Phrases
shinkufencer
1
590
書くときにひと呼吸おいて考えてから 書いてほしいRailsコードの書き方 / Rails programing code that I hope you will consider if you really need it
shinkufencer
0
2k
とりあえず抑えておきたい Railsでの「テストの内容」の考えかた #kaigionrails /Test code concepts to keep in mind for now with Rails
shinkufencer
4
1.7k
before_actionとのつらくならない付き合い方 #kaigionrails / how to using "before_action" with happy in Rails
shinkufencer
5
6.2k
テストコード未経験者が RailsでそれなりにRSpecがかけるようになるまでの話 /Inexperience Rails developer ,Use Rspec
shinkufencer
2
1.2k
セイチョウのための一歩 ブログ習慣化のあゆみ
shinkufencer
1
1.7k
Other Decks in Technology
See All in Technology
Road to Single Activity Uncovered
yurihondo
0
100
RAG: from dumb implementation to serious results
glaforge
0
150
品質マネジメントで抑えておきたい2つのリスクを見分けて未来に備えよう #yapcjapan
makky_tyuyan
0
110
TypeScript x Raycast x AIで変える開発者体験
nagauta
1
270
Azure App Service on Linux の Sidecar に Phi-3 を配置してインテリジェントなアプリケーションを作ってみよう/jazug-anniv14
thara0402
0
510
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
3.6k
【完全版】Dify - LINE Bot連携 考え方と実用テクニック
uezo
2
530
エムスリー全チーム紹介資料 / Introduction of M3 All Teams
m3_engineering
1
320
CData Virtuality 日本ローンチイベントのKeynote
cdataj
0
230
入門 KRR
donkomura
0
110
電子辞書にステータスバーを実装する
puhitaku
0
110
Assisted reorganization of data structures
ennael
PRO
0
270
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
325
23k
What's new in Ruby 2.0
geeforr
341
31k
Teambox: Starting and Learning
jrom
132
8.7k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Infographics Made Easy
chrislema
239
18k
Creatively Recalculating Your Daily Design Routine
revolveconf
217
12k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Building Your Own Lightsaber
phodgson
102
6k
Facilitating Awesome Meetings
lara
49
6k
Raft: Consensus for Rubyists
vanstee
136
6.6k
How to name files
jennybc
77
99k
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