学習履歴一覧

183件中の 101-125件 を表示

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 9章、10章 学んだこと オブジェクト指向を用いた開発プロセス オブジェクト指向では、一つの作業に対してV字モデルを適用する。 また、V字モデルの各プロセスを、同じチームが一貫して担当する。 従来のウォーターフォール的な開発プロセスではない。 オブジェクト指向を用いた開発プロセスの優位性 現代では経済活動の複雑化に伴い、ニーズの多様化・変化が当然となった。 ソフトウェアにも、これらの変化に追従することが求められる。 変更を楽で安全にするオブジェクト指向の特徴は、現在の短期間の開発と変更を繰り返すというニーズにマッチした。 オブジェクト指向らしく開発するために 基本方針は、分析と設計を一体に進める。 ソフトウェア全体をわかりやすく整理するために、複雑な業務ロジックを、ドメインモデルを使用して整理する。 そのためには、以下を同じ技術者(またはチーム)が行う。 業務ロジックを理解するための「分析」 ソフトウェアによる実現を考える「設計」 分析と設計を同じ技術者(またはチーム)で進めるために 特に、以下の活動が重要となる。 対面の質疑応答 ラフスケッチ 質疑応答とその記録 つまり、良質なコミュニケーション。 作成するドキュメント ソースコード 各種設計書の役割を兼ねる テストコード 非機能要件文書の役割を兼ねる 利用者向けドキュメント 外部仕様書の役割を果たす 非技術者であるステークホルダーが、成果物を理解することにも応用できる 画面や帳票 要件定義書の役割を兼ねる データベース情報 システムの意図を示す、補強的な資料となる 全体を俯瞰できるドキュメント

設計

2022年05月03日(火)

2.0時間

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 8章 読了 学んだこと アプリケーション間連携 基本はデータのやり取り。 以下が代表的な方法。 ファイル転送 データベース共有 Web API メッセージング ■ファイル転送 ファイルをやり取りする両者でフォーマットを決め、フォーマットに従ったファイルをやり取りする方法。 以下の問題点がある。 ファイルをまとめて転送する設計になりやすく、リアルタイム性に欠ける 一度システムを構築してしまうと、ファイル形式の変更が困難 ■データベース共有 必要なテーブルやデータ範囲を共有する。 以下の問題がある。 データベースを直接共有するというセキュリティ上の問題 テーブルとプログラムが密結合となり、変更が困難に ■Web API HTTPエンドポイントを設け、エンドポイントを通してデータをやり取りする。 必要な情報のみやり取りでき、様々なシステムと連携可能。 以下の問題点がある。 設計の自由度が高い 一度公開すると、APIの変更が困難 「リクエストを送信してレスポンスを待つ」という同期型の処理方式が、運用面と性能面で制約となる ■メッセージング キューなどのメッセージング基盤を介してデータをやり取りする。非同期型の通信方式。 アプリケーションを疎結合化でき、並行処理によって大量のメッセージを捌くことができる。 以下の問題点がある。 メッセージング基盤のための設計・運用技術が必要 安定したメッセージング基盤の構築と運用 put と post の違い どちらもデータ登録用のメソッド。 putは、識別子を使用してデータの登録を行う。 識別子が合致するデータが存在すれば上書きし、存在しなければ新規作成する。 putは以下の理由により、postと比較して結合が密になる。 putを実行する側で、データソースの識別体系を把握しておく必要がある putの応答(≒ステータスコード)を定義する必要がある 応答内容の決め事が増え、結合が密になる 基本は、疎結合となる post を使用する。 postで更新(または削除)を行う 以下のように行う。 更新(または削除)用のURIを構築する https://api.example.com/books/1234/deletion 上記URIに対してPOSTメソッドを実行する クライアント側からすると、更新(または削除)を依頼するのみという形になる。 更新(または削除)処理は、サーバ側に隠匿する。 これにより、アプリケーション間の結合を疎にする。 良いWeb APIとは何か アプリケーションの組み立ての多様性を維持しつつ、組み立て側の負担が増えすぎない、必要十分な情報を提供するAPI。 なんでもできる一つの巨大なAPIは、呼び出すためのパラメータが非常に多く、これらをすべて把握しなければならないため使い勝手が悪い 小さすぎるたくさんのWeb APIは、呼び出し側で組み立ての負担が増える API 開発方法 試しに作ってみて、ニーズを満たすか検証を交えつつ、フィードバックを基に修正/拡張を繰り返す。 ■重要なポイント Web API用のフレームワークやライブラリを導入 Sprint MVCの「REST Controller」など APIドキュメントやテスト画面を自動生成するツールを導入 「Swagger UI」 など 迅速なフィードバック APIの成長サイクルを回す ■APIを複合したサービスの提供 複合サービスを提供する場合、どうしても利用者側の知識が入り込み、密結合化する。 基本、複合サービスは利用者側で構築してもらう。 複合サービスを提供する場合、APIの提供を、以下の二層に分離する。 複合サービスを提供する層 基本APIを提供する層 ドメインオブジェクトとWeb API ドメインオブジェクトとWeb API(ぶっちゃけJSON)の相互変換は、以下の理由により不都合が発生しやすい。 データ構造の不一致 関心事の不一致 データ構造の不一致 特に、データ項目が多い場合に発生する問題。 Web API側は、データのみに関心があるため、可能な限り単純な構造が良い。 一方で、ドメインオブジェクトは、業務ロジックを反映した階層構造を持つ。 どちらに寄せるかが大きな課題。 関心事の不一致 API利用者は、ドメインオブジェクトが持つすべての情報を必要とするとは限らない。 ドメインオブジェクトが期待するデータ項目が、すべて送信されるとは限らない。 ずれが小さい場合は、ドメインオブジェクトとJSONのマッピングで対応する。 ずれが大きい場合は、変換用の中間オブジェクトをプレゼンテーション層に実装する。 POST request (JSON) -> Request オブジェクト -> ドメインオブジェクト ドメインオブジェクト -> Response オブジェクト -> POST response (JSON) 変換オブジェクトの用意は必須ではない。 変換オブジェクトは、ドメインオブジェクトに、I/Fやクライアント側の都合(JSON対応など)を持ち込まないために利用する。 複雑な連携 関係者が増えると、Web APIが複雑化する(特に公開API)。 以下をはっきり分けて設計する。 コアとなる基本API どの利用者にも共通で提供するAPI 拡張API 基本APIを組み合わせて提供する複合API どの利用者にも共通で使用できるものを提供する 個別対応API 特定の利用者のニーズを満たすAPIの集合 Web APIを育てる 個別のニーズを満たしつつ、他の利用者のニーズとも合致したら共通APIに組み込んでいく。 このように、環境の変化に合わせてWeb APIを育てていくことで、APIの価値を高め続けることができる。 Web APIは進化するからこそ利用され続ける。利用され続けるからこそ、発展できる。

設計

2022年05月02日(月)

2.0時間

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 7章 読了 学んだこと 画面アプリケーション開発の難しさ 画面は、利用者の様々な要望に応える内に、徐々に複雑化する。 要望に応えるには、画面の表示処理に業務ロジックを埋め込むのが手っ取り早い。 しかし、この方法は、各クラスに業務ロジックが散らばる原因となり、ソフトウェアの複雑化を進める。 難しい原因 次の二つが主な原因 画面そのものが複雑 画面と表示ロジックと業務ロジックが分離できていない どちらも、「関心事が分離できていない」ことに起因する。 つまり、以下のように関心事を整理すると、複雑さを軽減できる。 一つの汎用的な画面ではなく、複数のシンプルな画面構成とする 画面表示のロジックと、業務ロジックを分離する 複雑さ軽減の方針 画面とドメインオブジェクトを、うまく連動させる設計を目指すことが方針となる。 画面は利用者にとって視覚的な表現であり、ドメインオブジェクトは論理的な表現。 どちらも利用者の関心事を違う角度から表現しているにすぎないため、これらは十分連動可能。 画面の関心事を小さく分けて独立させる 小さな関心事(タスク)に分けて、タスクごとに画面とロジックを用意する。 -> タスクベースのユーザーインターフェースの採用 複雑な処理は、小さなタスクを組み合わせて達成する。 画面とドメインオブジェクトを連動させる 主な選択肢 ドメインオブジェクトをそのまま画面表示にも使用する タスクベースのユーザーインターフェースを採用する場合に有効 画面表示専用のオブジェクトを用意する 万能画面を提供する場合に有効 ドメインオブジェクトに書くべきことを整理する 以下の3つの観点が重要。 論理的な情報構造はドメインオブジェクトで表現する 場合ごとの表示の違いをドメインオブジェクトで出しわける HTML の class 属性をドメインオブジェクトから出力する 論理的な情報構造はドメインオブジェクトで表現する ビューの記述を、以下の二つに分離させる。 物理的なビュー 画面表示する技術(≒HTML)に依存したビューの表現 例) 段落を<p>タグや<br>で表現する 論理的なビュー 「複数の段落」といった、論理構造だけを保持する 例) 段落をString配列で保持する。段落分けや改行は、物理的なビュー側で表現する 場合ごとの表示の違いをドメインオブジェクトで出しわける 画面表示している条件分岐を、ドメインオブジェクト側へ移動できないか検討する HTML の class 属性をドメインオブジェクトから出力する 例) ``` String readStatus() { if (isUnread()) return "unread"; return ""; } <p class="${mail.readStatus}"> ``` 加工や判断ロジックと、その結果どういった値を返すかは、ドメインオブジェクト側で保持しておくと良い。 画面表示ロジックにif文が現れるほうが問題。 可能な限り、画面とドメインオブジェクトの構造を一致させる 画面は利用者の関心事であり、画面とドメインオブジェクトが一致している状態は、利用者の関心事をとらえていることを意味する。 また、両者が一致している状態は、画面の変更にかかるドメインオブジェクトの変更箇所を発見しやすくなる。 つまり、変更が容易になる。 両者を一致させていく改善が、ドメインオブジェクトを洗練させる。

設計

2022年04月30日(土)

2.0時間

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 5章・6章 読了 学んだこと アプリケーション層の役割は進行役 プレゼンテーション層(画面)、データソース層(主にRDB)、ドメインモデルの三者のやり取りを制御する。 アプリケーション層に作成するクラスはごちゃごちゃしやすい。 試してみたい業務ロジックを、ひとまずアプリケーション層に記述する、ということが始まるため コードが重複していく原因 業務ロジックは、全部ドメインモデルで表現する。 業務ロジックを、一時的にアプリケーション層で実装する場合は、後で必ずドメインモデルへ移行させること。 ドメインモデルを育てる 業務への理解が進むにつれて、初期に作成したドメインモデルがイマイチに感じる。 最新のニーズを満たすよう、ドメインモデルを継続的に改善していく。 「ドメインモデルを育てる」という認識が大事。 ドメインモデル改善時、いい名前が見つからないときは、ドメイン知識の理解が足りていない可能性が高い。 ドメインエキスパートに相談してみよう。 アプリケーション層が複雑になる原因 大きく、以下の二つ。 プレゼンテーション層(画面)の影響を受ける データソース層(主にRDB)の影響を受ける プレゼンテーション層(画面)の影響を受ける ■なぜ複雑に? 画面を通して、利用者から様々な要望が生まれる。 利用者にとって、画面こそが、サービスの具体的な形であるため これらの要望を「ひとまずアプリケーション層で実装」することを繰り返すことで、アプリケーション層が複雑化する。 ■複雑さを軽減するには? ①独立性の高い、小さな部品に分離する 分離した小さな部品を組み合わせて、プレゼンテーション層からやってくる要求に対応する。 特に、登録系と参照系の処理を分離すること。 ②シナリオクラスの導入 アプリケーション層を、以下の二つに分離する。 基本サービスを提供する「サービスクラス群」 基本サービスを組み合わせて複合サービスを提供する「シナリオクラス群」 サービスクラス群だけでは、どこに何が書いているのかわかりにくく、見通しが悪い。 シナリオクラスの導入で、シナリオ(≒業務知識)からトップダウンでサービスクラスを追跡できるようになり、見通しが改善される。 キーワードとして、以下を説明されていた。 契約による設計(DbC) 防御的プログラミング データソース層(主にRDB)の影響を受ける ■なぜ複雑に? 業務要件が複雑になると、insertやselectのタイミングも複雑になる。 そのため、どうしても手続きの羅列になる。 手続きの羅列は、以下につながる。 ロジックの散在 ロジックの重複 ■複雑さを軽減するには? リポジトリパターンを用いて、データベース操作ではなく、業務の関心事単位でメソッドを作成する。 以下をリポジトリ内部に隠ぺいし、サービス側から意識させないようにする。 DBへの操作(SQLなど) 業務としては、注文が登録できれば良いわけで、SQLの詳細は気にしたくない テーブル設計の詳細(複数のテーブルにCRUDするなど) 業務としては、注文が登録できれば良いわけで、複数のテーブルにCRUDするルールなんて気にしたくない コトに注目するデータベース設計 データベースの本質は、事実(≒コト)の記録。 事実(≒コト)の記録を徹底することが基本。 ことを正確に記録するために、 Not null 制約、 unique 制約、 外部キー制約を十分に活用すること。 以下の工夫は、ヒトやモノとの関係を正確に記録することに貢献する。 記録のタイミングが異なるデータはテーブルを分ける 記録の変更を禁止する 修正したい場合、「赤黒処理」と同等の処理を行う カラムを追加する場合は、テーブルを追加する コト中心設計の問題点 ことを正確に記録することを目指したDB設計では、カラム数の少ないテーブルが多数作成される。 現在の状態は、過去の記録を集計することで導出できる。 しかし、現在の状態を参照するたびに集計が走るのでは、性能面で問題がでる。 これを緩和させる手段として、インデックス機能の活用とイベントソーシング設計が挙げられる。 その他の工夫 update よりも delete & insert 「記録(入金記録など」」処理と、「状態(残高など)の更新」処理は独立させるべき 言い換えると、状態の更新に失敗したからと言って、記録処理を取り消す必要はない コトの記録と、集計情報やコトの記録のサブセットの参照を分ける イベントソーシングにより集計情報を更新する イベントソーシングを用いた設計は、修正や拡張の柔軟性を高める。 一方で、非機能要件やシステムの運用面からみると、検討するべき課題が多い。

設計

2022年04月29日(金)

3.0時間

React 基礎

やったこと Udemy : モダンJavaScriptの基礎から始める挫折しないためのReact入門 学んだこと Javascript スプレッド構文 const ary1 = [1,2] console.log(...ary1) # 1 2 配列を展開することができる。 使い道は思いつかないが、任意の変数をバラこともできる。 const ary1 = [1,2,3,4] const [num1,num2,...ary3] = ary1 console.log(num1) # 1 console.log(ary3) # [ 3, 4 ] 配列を展開は、shallow copy。 const ary1 = [1,2,3,4] const cp_ary1 = [...ary1] console.log(ary1) # [ 1, 2, 3, 4 ] console.log(cp_ary1) # [ 1, 2, 3, 4 ] cp_ary1[0] = 100 console.log(ary1) # [ 1, 2, 3, 4 ] console.log(cp_ary1) # [ 100, 2, 3, 4 ] 配列のjoinにも応用できる。 const ary1 = [1,2,3,4] const ary2 = [5,6,7,8] const join_ary = [...ary1,...ary2] console.log(join_ary) JSのmap関数 中間処理も終端処理のどちらも書けることに違和感。 慣れるしかないか。 const ary1 = [1,2,3,4,5] ary1.map((num) => console.log(num)) # 終端処理 const ary = ary1.map((num) => num * 10) # 中間処理 console.log(ary) # [ 10, 20, 30, 40, 50 ] map 関数 indexも扱うことができる。 const ary1 = [1,2,3,4,5] ary1.map((num,index) => console.log(`i: ${index}, number : ${num}`)) node map_filter.js i: 0, number : 1 i: 1, number : 2 i: 2, number : 3 i: 3, number : 4 i: 4, number : 5 JSの論理演算子 JS の || 左辺が false の場合、 右辺を実行する。 JS の && 左辺が trureの場合、 右辺を実行する。 bashの || と && みたい

React

2022年04月24日(日)

2.0時間

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 4章 途中まで 学んだこと ドメインオブジェクトの見つけ方 大前提 最初から、必要なドメインオブジェクトをすべて発見することはできない。 開発を進めながら、必要なドメインオブジェクトを見つけつつ、ドメインモデルに加えていく。 見つけ方 重要な関心事や関係性に注目する 業務の関心事を分離してみる コトに注目する ■重要な関心事に注目する やみくもに探すのではなく、業務にとって重要な関心事から発見してく。 ■業務の関心事を分離してみる 業務の関心事を ヒト/モノ/コトに分離する ヒト : 行動の主体 個人、企業、担当者など モノ : ヒトが業務を遂行する時の、関心の対象 商品、サービス、店舗、場所、権利、義務 など コト : 業務活動において発生する事象。記録や通知の対象 予約、注文、支払い、出荷、キャンセルなど コトを表現するオブジェクトは、以下の一般的な属性を持つ。 対象 : 何についての発生した事象か 種別 : どういう種類の事象か 時点 : いつ発生した事象か ■コトに注目すると全体の関係を整理しやすい コトは、業務の専門家であれば、無意識によって一連の事象を把握している可能性が高い。 コトは、ヒトとモノとの関係として出現する コトは時間軸に沿って明確な前後関係を持つ 専門家が当たり前だと思っている、隠れている業務ルールが発見できる 業務ルールの正確な理解が、業務知識を正確に反映したドメインモデルの形成につながる アプローチ 部品を特定し、その部品ごとに独立したクラスを設計する。 設計したクラスを組み合わせて、小さな業務ロジックを構築する。 組み合わせる中で、部品の調整や、不足していた部品の追加設計を行う 初めから全業務ロジックを扱わない ドメインオブジェクトの設計パターン ■ドメインオブジェクトの基本の設計パターン 値オブジェクト 数値、日付、文字列をラッピングしてロジックを整理する コレクションオブジェクト コレクションをラッピングしてロジックを整理する 区分オブジェクト 区分の定義と区分ごとのロジックを整理する 列挙型の集合操作 状態遷移ルールなどを列挙型の集合として整理する ■業務の関心事パターン 口座パターン 現在の値を表現し、妥当性を管理する 関心の対象を「口座」として用意する 数値の増減の「予定」を記録する 数値の増減の「実績」を記録する 現在の口座の「残高」を算出する 期日パターン 約束の期日と判断を表現する 約束を実行すべき期限を設定する 設定した期限までに約束が適切に実行されることを監視する 期限切れの危険性について事前に通知する 期限までに実行されなかったことを検知する 期限切れの程度を判断する 方針パターン 様々なルールが複合する、複雑な業務ロジックを表現する ルールの集合を持ったコレクションオブジェクトを作る 状態パターン 状態と、状態遷移 [ 可能/不可能 ] を表現する ドメインオブジェクトの改善 クラス名やメソッド名の変更 ロジックの移動 方針 : ドメインオブジェクトを使用する側のコードが、シンプルになるよう改良を続ける 取りまとめ役のクラスの導入 プログラムの自己文書化 ソースコードにて、業務の要求仕様を表現すること。 パッケージ名 / クラス名 / メソッド名 / 変数名に、業務の用語を使用する プログラムの意図が明確になり、どこに何が記述されているのかわかりやすくなる。 ドメインモデル設計 まとめ ドメインモデルの設計とは ... 業務を学びながら、業務知識を増やし、より深く理解してく 学んだことをコードで表現し、ドメインオブジェクトの設計に反映させていく 業務を学びながら、早い段階から実際にコードを書き、業務知識への理解とともに段階的にコードを成長させること。

設計

2022年04月24日(日)

2.0時間

React 基礎

やったこと React チュートリアル Udemy : モダンJavaScriptの基礎から始める挫折しないためのReact入門 学んだこと 仮想DOM 従来 DOMを直接操作していた。 これはレンダリングコストの増加、コードの複雑化を招いた。 仮想DOMの登場 DOMを直接操作するのではなく、仮想的なDOMを生成し、これに対して変更を加える。 そして、仮想的なDOMと実DOMの差分のみ、実DOMに変更を加える。 差分のみDOM操作するため、従来手法よりDOM操作量が減り、高速となる。 モジュールバンドラー モジュール(部品)をバンドルする(束ねる)という、文字通りの機能。 複数ファイルを一つにまとめることで、通信コストが下がり、高速化が期待できる。 イメージはzip圧縮。 代表的なサービスはWebpack。 トランスパイラ 新しいJavascript構文を、古い構文に変換する機能。 開発したJavascriptを、どのブラウザでも動作させることを目的とする。 登場した背景 利用者が(新しいJavascript構文に対応していない)古いブラウザを使用している可能性がある。 そのような古いブラウザでもWEbアプリを利用できる(≒Javascriptを動作させる)ために、新しいJavascript構文を、古いでもブラウザでも動作する古いJavascript構文に変換したいという需要が生まれた。 Javascriptの変数アレコレ var 上書き OK 再代入 OK まず使用しない。 let 上書き OK 再代入 NG 'xxx' has already been declared. 基本はこれ。 const 上書き NG Assignment to constant variable. 再代入 NG 'xxx' has already been declared. いわゆる、他言語でいう定数。 constでは、再代入を防ぐことはできても、オブジェクトの変更は防げない。 言い換えると、constは、オブジェクトの不変性は担保しない。 分割代入 const user = { name: 'test', age: 20 } const {name,age} = user // ココが分割代入 console.log(`name: ${name}, age: ${age}`) user.name の方が、 name だけよりも情報量が多い。 name だけだと、何の名前かわからなくなりかねない。 これは、分割代入処理と、代入した変数を使用する箇所が離れるほど、わからなくなりそう 一方で、 user.name 、 user.age と、何度も user. を繰り返すのは冗長に感じる。 自分なりの結論 : 分割代入した変数と、分割元のコレクションは、なるべく近くで使う方がよさそう。

React

2022年04月23日(土)

2.0時間

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 3章 輪読会参加 現場で役立つシステム設計の原則 4章 学んだこと 複雑な業務ロジックを実装する場合は、ドメインモデルの利用を推奨 ドメインモデル ドメインオブジェクトを集めて、体系的に整理したもの。 アプリケーションの対象領域の関心事を、データとロジックが一体となったオブジェクトとして分析し、その分析結果をそのままクラス設計に反映させる手法。 ドメインオブジェクト 業務の関心事を表現したオブジェクトのこと。 クラス名やメソッド名に、業務で使用する用語を用いる。 単なる用語の羅列ではなく、各用語の関連性をパッケージやクラスの参照関係で表現し、業務そのものを表現する。 ドメインモデルを開発する やることは、大きく以下の二つ。 分析 : 人間のやりたいことを正しく理解する 設計 : 人間のやりたいことを、動くソフトウェアとして実現する方法を考える ドメインモデルを採用する利点 業務の関心事が、そのままドメインオブジェクトに反映されるようになる。 利点1 修正や機能追加が楽に 業務の関心事をうまく整理できていれば、どこに何が書いてあるのか発見しやすくなる。 これは、修正や機能追加に、迅速に対応できることを意味する。 利点2 変更が楽になる うまく設計されたドメインオブジェクトは、他のドメインオブジェクトと最低限の依存関係を構築する。 プログラムを変更しても、他の個所に変な影響を与えるといったことが減る。 分析と設計を同じ人が担当すると、分析と設計が乖離しにくくなる。 ドメインモデルをどうやって作っていくか 手続き型のアプローチ 大まかな全体像を定義し、分割と細分化を進める。 いわゆるトップダウン。 オブジェクト指向のアプローチ 小さな部品を作り、それらを組み合わせて全体像を作り上げる。 重要な部分から作っていく。 開発を進めつつ、修正や拡張を繰り返しながらドメインモデルを充実させていく。 いわゆるボトムアップ。 全体を俯瞰する オブジェクト指向にて、全体を俯瞰する道具 パッケージ図 業務フロー図

設計

2022年04月21日(木)

3.0時間

現場で役立つシステム設計の原則

やったこと 現場で役立つシステム設計の原則 3章 読了 学んだこと 従来の設計とその問題点 データを格納する「データクラス」とロジックを記述する「機能クラス」の二つに分けるのが一般的。 問題点 開発が進むにつれ、あらゆるロジックが「機能クラス」に集約されていく。 結果として、以下の問題が発生する。 同じ業務ロジックが重複して記述される 見通しが悪くなり、特定の業務ロジックを見つけるのが困難に ■同じ業務ロジックが重複して記述される データクラスは、どこからでも(三層アーキテクチャであれば、あらゆる層から)アクセスできるように設計されることが多い。 結果として、データクラスを使用したロジックは、どこにでも書くことができてしまう。 データクラスにロジックを書くことを是としない結果、以下の処理のセットがいたるところで記述されるようになる。 データクラスからデータを取り出す 取り出したデータを使用して何らかの処理を行う ■見通しが悪くなり、特定の業務ロジックを見つけるのが困難に 「機能クラス」にあらゆるロジックを記述するため、開発が進むにつれて記述が膨れ上がり、目的のロジックを見つけるのが困難になる。 「データクラス」と「機能クラス」に分けるという設計は、オブジェクト指向の意図とは正反対 オブジェクト指向は、ドメイン知識について、データとふるまい(ロジック)を一か所にまとめて書くことを意図している。 従来の設計は、データとふるまいを分離するという、正反対の方向に舵を切っている。 従来の設計は、手続き型の設計である。 手続き型言語のやり方をオブジェクト指向でなぞった結果が、従来の設計の誕生だ...と、書籍では述べている。 データクラスの弊害 アプリケーション層の構造が画面の構造に引きずられる アプリケーション層の構造がデータベースの都合に影響される クリーンアーキテクチャ風に言うと、「詳細」側に依存してしまう設計となってしまう。 汎用クラスは使用されない 業務ロジックの重複を避ける手段として、「汎用クラス」が用いられる。 業務ロジック別に細かなニーズが異なる。 これに対応するために、以下のどちらかが取られる。 汎用クラスに引数を設定し、引数にて細かなニーズを満たすよう処理を分岐させる 引数による処理の分岐を把握する必要がある 引数が増えると、既存のコードが全部書き直し 細かなニーズ別にメソッドを用意する 大量に生まれるメソッドの細かな違いを把握する必要がある どちらの手段を選択しても、最後は「自分で書いたほうが早い」という結論となってしまい、誰にも使用されなくなる。 業務ロジックをわかりやすく整理するための基本アプローチ データとロジックを一体にして業務ロジックを整理する あるデータについて、データそのデータを使用するロジックを、一つのクラスにまとめる 三層のそれぞれの関心事と業務ロジックの分離を徹底する つまり、凝集度を上げる。 ここでいう凝集は、 「切っても切れない」関係。 凝集度が高い(≒「切っても切れない」)データと業務ロジックのみで構成されたクラスを設計していくことが、基本方針。 所感 データクラスを使用したロジックは、どこにでも書けてしまう問題について。 良くない書き方が可能な状態であれば、(将来含め)誰かが良くない書き方をする。 これは運用でカバーするのではなく、言語機能でカバーするべき。 今回の例だと、データクラスをパッケージプライベートで宣言し、他の層から見えないようにする...といった対策が考えられる。

設計

2022年04月20日(水)

1.0時間

network系の学習

やったこと ネットワークスペシャリスト 令和元年 午後Ⅰ-2 令和元年 午後Ⅰ-3 学んだこと ラウンドロビンは、「順番」に振り分けるもの 均等に振り分けるものではない。 ARPスプーフィングによる野良PCのアクセス制御 野良PCからのARPリクエストを、アクセス制御を司る端末が応答を偽造する。 ARPスプーフィングも、正しく使用することでセキュリティ効果に役立てることができるという事例。 DHCP 復習 DHCPによるIPアドレスの払い出しは、ブロードキャストドメイン内でのみ行われる。 言い換えると、ルータを超えられない。 DHCPの流れ DHCP DISCOVER (ブロードキャスト) DHCP OFFER (ユニキャスト) DHCP REQUEST (ブロードキャスト) DHCP ACK (ユニキャスト) DHCP REQUESTがブロードキャストである理由 ■ 前提 同一ネットワーク上に、DHCPサーバが複数存在することを想定する。 ■理由 DHCP OFFER を送信したDHCPサーバは、DHCP REQUESTを受け取り次第、DHCP ACKを返す。 他のDHCPサーバは、DHCP OFFERに含まれるIPアドレスが払い出されることを知ることができる。 つまり、「このIPアドレスをこれから使います」ということを、全DHCPサーバに通知する目的で、ブロードキャストにてDHCP REQUESTを送信する。 DHCP リレーエージェント DHCP クライアントとDHCPサーバが別セグメントに存在する場合、DHCPクライアントが送信する DISCOVERとREQUESTを、DHCPサーバが存在するセグメントへ中継する機能。 レイヤー3のネットワーク機器に搭載されている。 DISCOVERとREQUESTはブロードキャストのため、ルータを超えられない リレーエージェントにて中継した時点で、DISCOVERとREQUESTはユニキャストとなる。 DHCP クライアント --- ブロードキャスト ---> リレーエージェント --- ユニキャスト ---> DHCP サーバ DHCP スヌーピング DHCP関連パケットを監視すること。 これにより、正規のDHCPサーバから払い出されたIPのみ通信を許可するといった通信制限を課すことができる。 L2SWに搭載されている。 ■Trusted設定 L2SWのポートに対して行う、「DHCPスヌーピング、および通信制限を課さない」という設定。 このポートに接続されたセグメントは、通信制限が課されることなく、自由に通信できる。 DHCPサーバあての通信や、固定IPアドレスを持つ機器のために使用する。 ■Untrusted設定 L2SWのポートに対して行う、「DHCPスヌーピング、および通信制限を課す」という設定。 このポートに接続されたセグメントでは、式のDHCPサーバから払い出されたIPアドレスからのみ通信が可能となる。 言い換えると、正規のDHCPサーバが関与しない、不正なIPアドレスを使用した通信をブロックする。

network

2022年04月10日(日)

2.0時間

network系の学習

やったこと ネットワークスペシャリスト 令和三年 午後Ⅱ-2 令和元年 午後Ⅰ-1 学んだこと BGP 動的ルーティングプロトコルの一種。 比較的大きなネットワーク同士で経路情報を交換するのに使用する。 AS内で行う情報交換するためのBGPを iBGPと呼ぶ。 AS同士で行う情報交換するためのBGPを eBGPと呼ぶ。 BGPピア 二台のBGPルータ同士が、BGPプロトコルで情報交換している状態を指す。 基本的に、ピアごとに設定が必要。 iBGPによるピアを iBGPピアと呼ぶ。 eBGPによるピアを eBGPピアと呼ぶ。 BGPピアグループ BGPピアの対象をひとつにまとめる機能。 BGPピアの設定を簡略化できる。 通信時は、以下の構図となる。 BGPルータA 対 BGPピアグループ BGPルータAとピアを張りたいルータを、BGPピアグループに所属させる。 iBGP スプリットホライズン iBGP 広報のルール。 ルータAからルータBへ広報した内容を、ルータBからルータCへ広報できないようにする。 ルータCがルータAからの広報を受け取りたい場合は、ルータAとルータCとの間でピアを確立する必要がある。 これらを言い換えると、スプリットホライズンは、推移的な広報を禁じるルール。 https://milestone-of-se.nesuke.com/nw-advanced/bgp/bgp-summary/ VLANにおける、L2SW間の回線数 port VLAN VLANの数だけ必要。 タグVLAN 一本で済む。 これは、フレーム中のVLANタグに、VLAN情報を埋め込み、この情報を使用してVLANを識別するため。

network

2022年04月09日(土)

2.0時間

network系の学習

やったこと 令和三年 春 ネットワークスペシャリスト午後Ⅱ 学んだこと RSTP Rapid STP。 STPによるフェイルオーバーを高速化したプロトコル。 高速化のメカニズム 以下の二つにより、高速なフェイルオーバーを実現している。 有事の際に備え、事前に代替となるポートを設定する 待機時間のない、高速な状態遷移 ■ 1. 有事の際に備え、事前に代替となるポートを設定する ポートが故障したときに備え、代替となるポートを事前に決定しておく。 有事の際は、代替ポートを開放する(フォワーディング状態へ遷移する)ことで素早くフェイルオーバーする。 ■ 2. 待機時間のない、高速な状態遷移 STPでは、有事の際、以下の順でスパニングツリーを構成する。 問題発生 リスニング状態 ラーニング状態 転送遅延に設定した待ち時間が経過した後、ラーニング状態になる フォワーディング状態(完成) 転送遅延に設定した待ち時間が経過した後、フォワーディング状態になる RSTPでは、有事の際、以下の順でスパニングツリーを構成する。 問題発生 代替ポートをフォワーディング状態へ(完成) RSTPは、STPと比較して、待ち時間がなく、遷移する状態数も少ない。 これが、フェイルオーバーの高速化に寄与している。 DHCP リレーエージェント giaddrフィールド DHCP DISCOVERを発信してきたサブネットを特定するために使用する。 DHCPは、サブネットごとに、割りあてるpublic IPアドレスの範囲を定義する。 割り当てるpublic IPアドレス範囲を特定するために、DHCP DISCOVERを発信してきたサブネットを特定する必要がある。 この特定に、giaddrフィールドが使用される。 ループバックインターフェース 分類はネットワークインターフェース。 物理的なNICは存在せず、OS上に仮想的に構成されたネットワークインターフェースである。 通常のNIC同様、自由にユニキャスト用IPアドレスを付与できる。 BGP経路冗長化におけるループバックインターフェースの活用 ■活用するメリット インターフェース障害、リンク障害に対して強くなる。 物理NICに依存しない経路冗長化が可能 ルーター本体がダウンしない限り、自動で冗長経路を使用する ■活用しない(≒物理NICのみ使用する)デメリット 物理NICの数だけ、経路の冗長化設定が必要。

network

2022年04月08日(金)

2.0時間

Amazon Timestream 概要をつかむ

やったこと 以下の勉強会に参加 https://awsbasics.connpass.com/event/239665/ 学んだこと Amazon Timestreamとは 時系列データの扱いに特化した、サーバーレスのデータベース。 スケーリングも含めて完全マネージドサービス。 コスト最適 Amazon Timestreamは、以下二つのストレージで構成される。 高価だが高速なストレージ 安価だが低速なストレージ S3のようにライフサイクルポリシーを設定可能。 これらを組み合わせて、コストの最適化を図ることができる。 ユースケース 収集したデータを、一時間だけ高価で高速なストレージへ。一時間経過した場合、安価で低速なストレージへ。 -> 収集後一時間は、高速なクエリが可能。それ以降は安価なストレージへ移行して、コスト最適を図る。 時系列専用のデータモデル 以下の処理を柔軟に実施可能なデータモデルを構築している。 タイムスタンプをキーとした高速なデータ取得 属性情報の付与 時系列処理用関数 以下をはじめとした、時系列処理用の関数を提供。利用者側で実装する必要がない。 平滑化関数 ... ノイズデータを除去しつつ、データを均一化 補完関数 ... 欠落データを推測し、補完する 構成要素 Table 時系列データの集合を保持する要素。 RDBのテーブルに相当。 Record 一つ分のデータ。 RDSの行、またはレコードに相当。 Recordは、Dimension(メタデータ群)とMeasure(データ群)で構成される。 Dimensionはクエリ時のキーとして使用できる。 Time - Series テーブルから、特定の属性値で絞込をかけたレコード群。 location : tokyo , sensor_id : hogeのレコード群 など

AWS

2022年03月28日(月)

0.5時間

network系の学習

やったこと ネットワークスペシャリスト合格教本 2022年 サーバ負荷分散 サーバ冗長化 経路冗長化 NIC 冗長化 学んだこと LBによる負荷分散 外部からのリクエストを、LB管理下のサーバに振り分ける。 その際、外部からのリクエストの宛先IPは、LBから振り分けられたサーバに変換する。 動作的には、リバースプロキシに近い。 LB管理下のサーバのヘルスチェックも可能 レイヤーに応じて、ヘルスチェックの手段が異なる レイヤー3 : pingを使用 レイヤー4 : TCPセッションの確立を試みる レイヤー7 : 特定のリクエストを送信し、そのレスポンスを確認 ヘルスチェック機能を実現できる点は、DNSによるラウンドロビンには無い利点。 LBの振り分け戦略 色々ある。 ラウンドロビン 事前に振り分け比重を決める 事前に優先度を決める レスポンスが最短のサーバ コネクションが最小(≒まだまだ余裕のある)のサーバ 何かしらの個別ルール DSR (Direct Server Return) LBを通したリクエストについて、レスポンスはLBを通過しないという戦略。 ■request経路 client -> LB -> server ■response経路(DSR) client <- server 利点 LBの負荷軽減 LB周辺ネットワークの帯域節約 特徴 VIPを用いてLBからserverへ振り分ける時、VIPは変化せず、MACアドレスのみ(LBからserverのMACアドレスへ)変化する。 DSRを使用する場合は、サーバー側には以下の設定が必要。 LBと同じVIPを設定する クライアントとやり取りするため、IPアドレスが必要 LBと同じIPアドレスであれば、クライアントは、サーバのレスポンスをLBのレスポンスとして解釈できる -> サーバとLBのVIPが異なる場合、クライアントからすると、LBに送信したはずのリクエストが、LB以外のIPアドレスからレスポンスとして帰ってくることになり、通信が成立しなくなる VIPに対する ARP に応答しないこと ARPに応答するのはLBとするため LBによるセッション維持 ■背景 現代では、Cookieを用いたステートフル通信が浸透している。 このため、セッションが維持されている限り、通信相手は(LBで振り分けた)サーバと同一である必要がある。 これを実現するのがセッション維持機能。 ■仕組み LBによって異なる ■セッションIDを識別するために Cookieの中身を確認してセッションIDを識別する場合、HTTPSパケットを復号する必要がある。 これは、LBにこの機能を持たせる(≒LBにTLS終端機能を搭載する)ことで解決できる。 サーバの冗長化 スタンバイ系へのフェイルオーバー サーバからクライアントへ、RSTフラグを立てたTCPを送信し、(障害が発生した)アクティブサーバとのTCPセッションを強制切断する。 これにより、迅速なフェイルオーバーをじつげんする。 スプリットブレインシンドローム active/ stand by 構成のシステムにおいて、何らかの理由(主にハートビートの失敗)で、障害が発生していないにもかかわらずstand by系が起動する事象。 ■問題点 仮想IPのARPに、active系とstand by系の両方が応答してしまう ディスクを共有している場合、保存しているデータにて競合が発生する可能性が高い マルチホーミング(回線冗長化) 切断が許されないサービスを提供するサーバ(DNS、NATなど)への回線を冗長化することで、より確実なサービス提供が可能となる。 冗長化した回線を使用して、LBによるトラフィックの負荷分散を行う...といった戦略もある。 NICチーミング(Teaming) 複数のNICをまとめ、一つのNICに見せかける技術。 リンクステートトラッキング L2SWに備わっている機能。 あるポート(上位ポート)がダウンした時、他のポート(下位ポート)を強制的にダウンさせる機能。 STPは、ブロードキャストドメインごとにスパニングツリーを一つ形成する 以上

network

2022年03月27日(日)

2.0時間

network系の学習

やったこと ネットワークスペシャリスト合格教本 2022年 VRRPまわり 学んだこと スイッチ スタック接続 複数のスイッチを、一台の仮想的なスイッチとして扱う技術。 ラックに積まれているスイッチ群のイメージ。 https://e-words.jp/w/%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E6%8E%A5%E7%B6%9A.html スタック接続している(一つにまとめられた仮想的な)スイッチでは、リンクアグリゲーションを使用できる。 LACP リンクアグリゲーションとして設定した回線のヘルスチェック、障害発生時のフェイルオーバーを行うプロトコル。 スパニングツリー 再構築中は通信できない 以上 MPLS パケットにラベルを付与し、様々なプロトコルに対応させる技術。 ネットワーク層(ラベル付与と削除)、データリンク層(ラベルを参照した独自ルーティング)で動作する。 主に、以下を実現するために使用される。 VPN QoS 今日では、品質向上よりも、付加サービスの提供に重きが置かれている。 https://www.infraexpert.com/study/mpls1.html VRRP (Virtual Router Redundancy Protocol) ルータを冗長化するためのプロトコル。 複数のルータを、一台のルータのように見せかける技術。 一台のマスタールータと、一台以上のバックアップルータで構成される。 動作的にはActive/Stand by。 マスタールータが定期的に広告を送信することにより、他の機器はマスタールータが動作していることを知ることができる。 言い換えると、マスタールータからの広告が途絶えた場合、マスタールータがダウンしたと判断され、フェイルオーバーを実施する バックアップルータは、GRAPを送信することで、他のSWのMACアドレステーブルを更新する。 例) VRRPによる仮想MACアドレスをXXXXとする 正常時 SW1のMACアドレステーブル port1 : XXXX port2 : - 障害発生時 port2からGARPを受け取り、MACアドレステーブルを以下のように更新する port1 : - port2 : XXXX https://milestone-of-se.nesuke.com/nw-basic/fhr-redundancy/vrrp/

network

2022年03月26日(土)

2.0時間

network系の学習

やったこと ネットワークスペシャリスト合格教本 2022年 ** OSPF周り DDD 輪読会参加 学んだこと 代表ルータ、バックアップ代表ルータ OSPFのマルチアクセスネットワークにおいて、Link State情報のやりとりを中心的に行うルータのこと。 背景 ルータの数が多いほど、OSPFのLink State情報のやり取りが増大する。 (ルータN台とすると、やり取りするペアの数は N * (N - 1) / 2) 代表ルータを選出することで、各ルータは代表ルータとのみやり取りすれば良くなるため、ペアの数を減らす(≒ルータの負荷減少)ことができる。 パッシブインターフェース ルーティングプロトコルパケットを送信しないインターフェースのこと。 OSPFルータが存在しないインターフェースに設定することで、ルーティングプロトコルパケットの送信を抑制できる。 これにより、無駄なルーティングプロトコルのパケット送信(≒帯域の浪費)を抑えることができる。 経路集約 ABRによるLSA実行時、サブネットの経路を集約して他のエリアに送信すること。 Link State情報が簡略化され、ネットワーク、OSPFルータの負荷を軽減できる。 0.0.0.0/0が最も集約された経路と考えると、イメージしやすい。 ドメインサービス 自分なりの理解 ドメインをモデル化してシステムに落とし込む過程で、どうしても「ドメインとは無関係だが、ドメインオブジェクトを作成するうえで必須の処理」というのが生まれる(例 : パーサなど) そういった、どこへの実装するのも不適切だが必要な処理を実装する場所がドメインサービス。 DDD 仕様 自分なりの理解 ドメインオブジェクトに実装するのは不適切だが、ドメイン知識として確実に存在する処理を実装する場所。 「ドメインオブジェクトに実装するのは不適切、かといって、ドメインサービスは絶対違うよね。なら、「仕様」という考えを作って、そこに実装しよう!」みたいなノリを想像した。

network
DDD

2022年03月24日(木)

2.0時間

183件中の 101-125件 を表示