kuntalog

師匠募集中

デプロイを高速化したい

やりたいこと

  • デプロイに時間かかるのなんとかしたい
  • Rails環境をDockerで作りたい
    • イメージを作っておいてそれをデプロイすれば早いはず!!
  • 環境はAWS
    • Elasticbeanstalkへのデプロイ
    • 今回はMulti-Containerやりません、ECSがつらいので
    • さらにこの辺を自動化したい(CI, CD)
続きを読む

ミック本読みました

 

いわゆるミック本を読みました。 

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

 
続きを読む

アーキテクチャパターンに関して調べてみた ~続き~

神記事を見つけました。

 

qiita.com

アーキテクチャパターンについて調べてみた

今日のスタートになった記事

Controllerは薄く書けとのことをひたすら読んだので実践したところ、ModelがFatになったり持っている機能の範囲が広くなりすぎたりするのが不満だったのと、2つ以上のModelにまたがった機能を実装するときその機能はどのModelの責任になるのかみたいな疑問に対してどんぴしゃでした。

これ読む前に自分でもアプリのユーザー体験に基づいた機能(ドメインロジックって呼ぶんでしょうか)を切り出して別クラスを作って、ModelをDBアクセスのためだけに使おうとかしてたんですが、なかなかうまく作れなかった。

 

その中で紹介されていた記事 

実際に自分が陥っている問題の具体化だとか、対策としてどういうものがあるかなどがはっきり書いてあったのでよかった(SQLアンチパターン読まなきゃな)。あと自分が作ろうとしていたものがサービス層というものだということ(全ッ然違うけど)が分かっていろいろ調べられるようになったし、DDDって聞いたことあったけどそういうことだったのね、とか。DDDの本やばそうですね。DCIってなんぞ。。。レイヤーアーキテクチャっての面白そうだな。

 

やっていこうとは思うけど、ここに書いてあることをやってそれが本質的な問題解決につながるようになるには経験もスキルも足りなさすぎるなぁという感じ。

 

Martin Fowler's Bliki in Japanese - ドメインモデル貧血症

上の記事のスライドの中で出てきた「ドメインモデル貧血症」の話。

ビジネスロジックはあくまでドメインに記述すべきもので、アプリケーション層なんかはそこにタスクを投げるだけにするという意味でControllerは薄く書くものだという意味だったんだなと理解。

 

railsとかのどうでもよいメモ: DCI (data context interaction)

DCIってなんぞってわけで読んだ。

DCIとは全く関係ないんですが

そういう意味で、例えばデザインパターンのような技術者だけの道具が設計の初期に出てくるのはおかしい。技術者はえてしてそういう技術話が好きなものだが、ラムダとかデザインパターンとかmix-inとか、ビジネスロジックの出てこない道具は「syntax上」の道具でしかなく、これはつまり局所最適化にしかなりえない。それを全体レベルの最適化に使ってもうまくいくはずがない。こういう道具は局所戦でしか使ってはいけない。

ってところ、その通りだと思います。肝に命じておきます。

でDCIについてはここにはあまり書いてなかったので

を読みました。軽めの内容で読みやすかったです。

実際にこれ実践できると、Roleなどに応じてコードをどんどん分割できて綺麗に管理できそうですね。でもDCIってのは僕の求めている類の対策というよりは開発手法なのかな。今から急に採用してってことはできなさそうです。もし今度もっと使うのであれば勉強しないといけないですけど、今はDDDの方に興味があります。

 

サービスを作るときの責任の持たせ方の参考になりました(OOが分かってない顔)。

 

上の記事と合わせて責任の分け目ってこういうところに作るんだなって。

 

2.4. アプリケーションのレイヤ化 — TERASOLUNA Global Framework Development Guideline 1.0.0.publicreview documentation

アプリケーションのレイヤー化についてよく分かってなかったので自分で読みやすいものを探してきた。

ドメイン層だけじゃなくてアプリケーション層なども合わせて読んで理解が深まりました。依存関係のところとかしっかり守ってカプセル化とかうまくやっていきたいです。

でもこれこのJavaフレームワークの思想はこうですよっていう内容だしDDD原本はまだ怖いので

https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html

の内容なんかを時間があるとき読もうと思います。

 

あんまりかいつまんだ勉強をしてもなんだか正しい理解なのか不安になりますね。。とりあえず自分で実践していくときは読んだ内容はあくまで参考としていくということにします。

アプリケーションっていうのは問題解決のためのものであり、コードはその解決のある部分を担うという意図を持って書かれている。コードはアプリの機能のロジックを実現するものであったり、他のコードからツールとしてだけ使われるものだったりする。そのような性質によってコードの置かれるべき階層などに分けて、コードの再利用やコード同士の疎結合を実現しようとしている。

ということだけ頭においておきます。

 

こんな理解であってるんでしょうか。

はじめまして

はじめまして、くんたおです。

大学生やってます。

留年したのをきっかけにベンチャー企業でインターンするようになりました。

そこでWebサービスを作っているのですが、作る過程で自分で調べたことなどをまとめていきたいと思います。

知識は人によどみなく話せる伝えらるものとなって初めて自分で使えるようになるものだと思っているので、丁寧にまとめることが自分のためになるとも思っています。

 

大きな流れのあるものに関してはそれをここに、更にそれらを細かなものに分けてQiitaなどに投稿していきたいと思います。

 

どの程度の更新頻度になるかはわかりませんが、少しでも役に立つことをかけたらと思います。