Twitterに書いた内容再掲。
最近Vuexについて考えてるのは、Vuex使ってPDS実現するとなると、状態はVuexのレイヤーで持つことになるから、モデル層はステートレスで作るのが相性良い（というか自然とそうなる）だろうな
その時にJSでイミュータブルに寄せて行く辛さがどれくらいキツいものなのかの知見が自分にはない
ある程度以上に複雑なアプリケーションでは、サーバーサイドからpushされる情報のためにコネクション握りっぱなしにする部分とかも出てくるであろうと思っていて、モデル層以下をイミュータブルに寄せて行った時にそういうのをどうハンドルすれば良いかも自分に知見がない
Vuex少し触ったところとても筋が良いと感じるんだけど、そのあたりみんなどうしているのか知りたいなあ
まあある程度の複雑さまでなら「Vuexの層に全部書く」でよいからそれでええやん、というのはありそう
イミュータブルモデルの良いところはテスタビリティがぐんぐんあがるよ！ってところだと思っていて、そのメリットは捨てがたいので知見貯めていきたい
ツイッターで書いた内容です
SPAやってると画面ごとに複雑さが全然ちがって、単なる一覧表示してる画面の複雑さといろいろな操作ができる画面の複雑さは雲泥の差になる
こういうときに、「この画面はきちんとドメイン層作ったほうが見通しがよくなるけど、この画面もそうしちゃうとオーバーキルなんだよな〜」ということがある
そういうときにアプリケーション内で一貫したアーキテクチャでやっていくのか、この画面はXの層をスキップしますとするのか、こーたえーはーなーい（ABSTRACT TRUTH / NUMBERGIRL）
「ディレクトリ構成、名前空間構成に貴様の 意思 を込めろ」という煽りを思いついたので自由に使ってください
ひとつのアプリケーションの中に複数の画面があり、画面ごとに複雑さが異なるような場合、やはり画面ごとにアーキテクチャを変えるというのが正解な気がしてきた。その場合、たとえばパッケージ構造は次のようにする
- presentation
- A
- B
- model
- transaction
- A transaction
- layered
- usecase
- B usecase
- domain
- infrastructure
その上で、domainとinfrastructureの下は画面構造に依存しない分割構造でパッケージを分ける
どうか。
しかし、これを実践するためには、意図をきちんと説明したら理解してくれるメンバーで開発を行う必要があり、弊社なら問題ないな
一つ前の記事にもある通り、掲題の通りの試みを行いました。
一応、「一通り書けたぞ！」という感じになったので、ここにてこのREADMEを Ver.1.0.0 メジャーリリースとします。
自分ではかなりわかりやすく整理できたつもりでいますが、まだまだ「えっここってどういうこと？わかりにくいな〜」という部分があったり、「あ、ここは間違いですね」といった部分があるかと思います。そういうときには是非 issue やブックマークなどでフィードバックをください。それをもとにさらに良いものに育てて行きたいと思います。
また、もしこのリポジトリがみなさんの一助になるようなことがあったとしたら、
のどちらかを是非！是非！！！！検討してみてください。twitter @neko_gata_s が誰からでもDMを受け付けるようになっているので、弊社に興味がある方はぜひメッセージをください。techblogもやってます。
最近はずっとJSでGUIを書くっていうお仕事をやっていて、その中で様々な知見が溜まってきてます。
そのときにひしひしと感じたんだけど、世の中にはさまざまなアプリケーション・アーキテクチャの話が溢れかえっていて、結構混乱を産んでいるように思います。
MVVMだけ見ても、「MVVMで実装しています」って主張しているものがMVVMパターンと違うパターンで実装されていたり、「軽量MVVM」なんて言葉が生まれていたりという状況があって、これはだいぶ混乱が極まっているぞ、と感じる状況です。
また「最近はClean Architectureが熱いらしい！MVVMを捨ててやってみよう！」とか言う発言を目にしたりして、「Clean ArchitectureとMVVMは矛盾しないからMVVMを捨てる必要はないんだよ！」って思ったりもするわけです。
そういう混乱の中にあるひと（それは知見を貯めるまえの自分のことでもあります）のために、今自分がきちんと理解している範囲で、様々なアプリケーション・アーキテクチャと、それぞれの関係みたいなものがきちんと説明できたらいいな、と思って、サンプルアプリケーション付きのリポジトリを作りました。
サンプルアプリ自体はGithubPagesで動いています（再生ボタン押すと音が出るので注意）。
README.mdに解説が書いてあります。
このサンプルアプリのアーキテクチャを解説していく中で、Presentation Domain Separation と MVVM と Layered Architecture と Clean Architecture について、整理された概念を読者が獲得していくことを目指しています。
と、いいつつ、実はこのREADME.md、「執筆中」って部分があるんですけど、まあ、そうです、まだ執筆中なんですよね。
とはいえ、すでに結構な分量が書かれたので、一旦ここで「こういうの書いてるよ！よかったら読んでね！」ってアナウンスしておこうかな、と思った感じです。
読んでいただいて、よかったら「よかったよ！」って言ってもらえると、続きを書くモチベーションにもなるので、心優しいひとは読んでみて、よかったら「良かったよ！」って言ってください……。
また、技術的な誤りなどが含まれている場合はIssueなどでご指摘を歓迎いたします。よろしくおねがいします。
最近立て続けにそのあたりの話をする機会があったので。わたしの意見です。
わたしはフレームワークのアップデートでアプリ全部に手を入れるの嫌なのでプロダクションではvuex使ってない。
このへんの話はYAPC::Kansaiで話したんだけど未だに発表再現ブログ書けてない。明日書けたら書く。
ぼくは最近、大人になるというのは取りも直さず、自らを物語るということなんじゃないか、と思うことがある。
ぼくたちは、自己だとか内面だとかいったものが先にあって、そいつらがぼくたちの選択や人生を駆動している、とついつい思いがちだ。けど、自己だとか内面だとかなんてほんとうは存在しなくて、それは「物語られる」ことによって遡及的に見出させれるようなものなんじゃないかな、ってぼくは思うことがある。
ぼくたちの精神や自己というものは、なんとなく一本筋の通った物語として理解される形で総合されたものとして普段は認識されている。たとえばぼく自身について語るなら、「文学部で哲学を学んでいたんだけど、御多分に漏れず哲学で就職できるわけもなく、趣味で書いてたプログラムでひとまず仕事を始めてみたら、これが趣味でやってたときよりもずっと奥が深くておもしろくてどハマりした。コミュニティ活動とかしていく中で、技術雑誌の記事の執筆のお話をいただく機会に恵まれ、思わぬ形で商業誌に自分の文章が活字として載ることになり、文学部のころの自分とプログラマとしての自分がなんだか面白い形で統合されていまの自分がある」といったような。
けど、ぼくたちの生というのは、ほんとうはこんなふうに「物語られて」いいようなものではないとも思う。この物語には、たとえば昨日食べたドーナツの味だとか、キャンパスの喫煙所で1人で喫煙してたときに隣でタバコを吸ってる二人組がしていた興味深いフランス思想の議論だとか、B tree indexを初めて理解した時の深い驚きと先人への尊敬だとか、なんとなくダラダラ過ごしてしまった日の夕方に友人から飲みに行かないかと誘われてアパートの部屋を出たときに見た夕暮れの色の後ろめたさとか、息子が「おかたづけ」を「おたかづけ」と発音してしまうこととか、そんな全てがまるっきり排除されてしまっている。
ただまあ、これは当然のことで、そんなすべてを物語に全部盛り込んでしまったら、「なんの話なんだこれは。なにが言いたいんだ貴様は」ということになってしまう。ぼくたちは、「無駄」なことを刈り込み、編集、編纂することで、自分にも他人にも理解可能な自己像や内面を、物語として騙るのだろうと思う。
そうして、ようやくぼくたちは自己を理解可能な形に調整し、他人とコミュニケーションをとり、社会を形作って行くんだと思う。だから、大人になる、ってことはたぶん自己を物語ることから始まるという一面がある。そんなふうにぼくは思う。
それでも、整理されて理解されやすい、遡及的に見出された内面だとか自己なんかより、もっと無指向ででたらめで、筋の通った物語として理解できない、あるいはされないような混沌、物語るときにとりこぼされてしまうような混沌を、ぼくは捨ててしまいたくない。それは物語られず、整合性がなく、だから理解不能で、社会的には「要らん」もので、けど、とても美しい（いや、こうして「美しい」と語ってしまった瞬間にそれは「美しさ」という言葉によって刈り取られ、スポイルされてしまうのだけれど）ものだ。
ぼくは、そんな混沌に混沌のまま触れたいからこそ、音楽を聴き、漫画を読み、小説を読み、お酒を飲み、仕事に関係なく役にも立たないコードを書き、こうした雑文を書くのだろう。いつまでも大人になりきれない、「要らん」ものを捨てられない子供なんだけど、それでもいいかな、と思ってしまうのだった。
弊社のwebAPIはRESTを捨てて操作指向のURLにすることが多いんだけれど、ここのところwebAPIだと結構そういう判断するところが増えてるように感じる（個人の感想です）。
SoEとSoRという話があったけれど、webブラウザ上でもスマートフォン上でもリッチなユーザ体験がモノを言うようになり、SoEなサービスが増えてきていることと操作指向のURLが増えていることは実は無関係ではないのではないか。
というのも、SoRの場合その性質上リソースに対する意識が高まるのに対して、SoEの場合はどちらかと言うとユーザ体験みたいなところに意識が高まる。で、ユーザがサービスを捉えるときのメンタルモデルって、「リソースの操作」とあまり一致しなかったりすると思うんですよ。そうすると、どうしてもリソース指向のURLでやっていくのに無理が出てきて、「じゃあいっそユースケース指向というか操作指向のURLでAPI作ればええんやないの。HTTPステータスも全部200で返してjson body見てね。」みたいな。
というようなことを最近なんとなく考えていました。
