すでにブログ更新が遅れ気味ですが、5 月のネクストスキルの週次ゼミのまとめです。

主にアプリケーションの設計周りの学習でした。

5 月に学んだこと

第 1 週

オブジェクト指向 について学びました。

• プログラミングのパラダイム
  • 機械語（アセンブリ） -> 手続き型 -> オブジェクト指向 -> 関数型
• オブジェクト指向
  • オブジェクト指向の要素
  • 継承より委譲
  • リスコフの置換原則
• そもそもプログラムはどうやって動いているのか（そこからオブジェクト指向的な観点）
  • スタックとヒープ（言語によって違うので注意）
• 分数プログラム
  • 手続き的な書き方から、データと処理を一緒にしてオブジェクト指向に。

ここらへんの話は知っているものが多かったですが、Ruby でのオブジェクト指向プログラミングの実装例を見れたのはよかったです。

少し話はずれるけど、OS 周りの話はより深く学習したいなと思いました。Linux もそうですが、OS 自作本などにチャレンジしたい。

第 2 週

アプリケーション設計について学びました。

• 3 層アーキテクチャ、MVC とは
  • アーキテクチャ is 何
    • CPU アーキテクチャ、アプリケーションアーキテクチャ、インテグレーションアーキテクチャ、インフラアーキテクチャ
  • アプリケーションアーキテクチャについて
    • 3 層アーキテクチャ
    • MVC(GUI アーキテクチャ)
• じゃんけん CLI(既存のプログラム)を MVC、3 層にする
  • Ruby でじゃんけんプログラムを 1 ファイルに書いた状態から、MVC、3 層アーキテクチャにしていく
  • トランザクションスクリプトから、ドメインモデルにする
• どんなコードをどこに書くべきか
  • プレゼンテーション層、ビジネスロジック層（アプリケーション層）に書くべきこと
• バリデーションどこでやるのか問題
  • フロントエンドか、サーバサイドか、両方か。

アプリケーション設計の話では、書いてもらった図がアプリケーション設計の全体像を俯瞰する上で気にいってます。以下は自分で書き写した図です。

アプリケーションの設計において、整理するにはすごくいい図だと思いました。

第 3 週

アプリケーション設計について、もう少し踏み込んで学びました。

• 開発のアプローチ
  • PoA, DoA, OoA
• 3 層アーキテクチャや MVC を使った基本パターン
  • MVC + ドメインモデル + ActiveRecord
  • 3 層 + MVC + トランザクションスクリプト + DAO
  • 3 層 + MVC + ドメインモデル + DAO
• 依存関係の整理、より高度なレイヤー構成
  • レイヤードアーキテクチャ（ドメイン層を用意する）
  • ヘキサゴナルアーキテクチャ（DI や DIP を使って依存を剥がす）
• データアクセスのパターン
  • OR マッパーの種類(JDBC のラッパー型から、クエリビルダー型など)
• その他発展的内容
  • N+1 問題
  • DDD
  • CQRS(CQS)
• アーキテクチャの選定
  • 初期実装コスト、メンテナンス性、学習コスト、フレームワークとの相性

ここは感じることが多かったので、少しつらつらと書いていきます。

「モデル」の意味には注意が必要だなと感じています。

MVC としてのモデルを表すのか、ドメインモデルのモデルを表すのか、文脈によって意味が違ってくるので、コミュニケーションを取る上では齟齬がないように注意が必要。

図にして説明する、定義を明記するなどの対応をするといいかもしれません。

次に、アプリケーションの実装において、プレゼンテーションでユーザの入力を受け取り、処理を実行していく流れが通常かと思いますが、DB の更新などでインフラストラクチャ側から入力を受け取って、ユースケースやドメインを呼ぶことも許されているようです。

ただし、ぱっと見アーキテクチャがわかりづらくなる危険性があったりするので、よく検討する必要ありとのこと。

これと関連して、この時、結果を表示する先として UI が存在している場合、たとえば Android だと LiveData や Flow などで UI に通知する、流すパターンがありますが、どの層でオブジェクトを管理すべきかなど、自分の中でまだうまく消化できておらず、整理できていない部分だと感じました。

最後に、要件やスケジュール感、開発チームに合わせて、アーキテクチャを適切に選択することが重要だと感じました。

高度な設計をただ導入すればいいというわけでもなく、コストが余計にかかる場合もありえるので、一概に高度な設計がいいわけではないと思いました。

チームメンバーの理解度や、言語の特性やフレームワークの特性などによってもやりやすさが違うので、総合的な判断が求められると思います。

第 4 週

受講者の事前アンケートに答える形式でした。

• マイクロサービスアーキテクチャ
  • デプロイの単位、メリット、デメリット
  • 初期コスト、メンテナンスコスト
  • 分散システム特有の問題
  • 選択のポイント
  • アンチパターン（共有データベース、共有ライブラリ）
• 情報セキュリティ関連の資格
• Linux 超入門
  • OS とは
  • プロセス、ファイルシステム
  • ハードウェアの抽象化
  • コマンド(組み込みコマンド、外部コマンド)
• サーバの用意ですること(インフラエンジニア)
  • キャパシティプランニング、調達、構成、監視、改竄検知 etc

マイクロサービスの話ですが、作るものがかっちり決まっているなら、いきなりシステムを分けて作るのもいいけど、スモールスタートで設計しておいて、良いタイミングで分けるのがいいのかなと思いました。

ただ、システムを分割するコスト嫌って後回しにしてしまうと、どんどん難しくなってしまいそうなので、そこは適切な判断が必要（これが難しいんだが）。

まとめ

5 月は、アプリケーションの設計周りについて、体系的に学べたと思います。ただ、実際の実装で困ることはたくさんでてくるはずなので、少しずつ実装例、対応パターンなどを貯めていきたいと思いました。

先月に引き続き、いくつか知らないキーワードを知ることができました。特にマイクロサービスまわりの話は特に知らないので、ポイントを知ることができてよかったです。

これから書籍などを参考に、優先度に合わせて深く学習していけたらと思います。