[戻る]

Java読書会BOF「セキュア・バイ・デザイン」を読む会 第9回

開催概要

日時

2023年3月25日 10:00 - 17:00

場所

てくのかわさき 第4研修室

出席者(敬称略)

高橋(徹)、吉本、岩室、根本、平山、加藤 (書記)

第12章 レガシー・コードへの適用

注釈

本日は、p.433 の冒頭から

  • (雑談) Java 20 リリース

    • Scoped Values (JEP 429) が新登場

    • 基本的に過去に出たものの nth Preview や nth Incubator が多い

    • Java 21 (LTS) での正式機能化に期待

    • JJUG ナイトセミナーが 3/31 にある模様 https://jjug.doorkeeper.jp/events/153863

12.1 レガシー・コードのどの部分にドメイン・プリミティブを適用するのか？

  • p.434 ドメイン・プリミティブを使うことは合理的で直感的ということに本当に異論はない・・・？

    • あまりにも多くのドメイン・プリミティブがあると (Java などの場合は) クラス数が膨大になって探したりメンテするのが辛い

  • p.435 誤植: 第2段落1行目、「境界付けられたコンテキストついて学び」→「境界付けられたコンテキスト に ついて学び」(に が抜けている)

12.2 メソッドやコンストラクタの曖昧な引数

  • p.437 修正しなくてはならないと認識できなくてはならないとあるが、IntelliJ などでは引数名が関数呼び出し時に出たりするので、それで良い場面もありそう

    • ただ、型が同じの引数が多いとミスは起こりうる

    • 引数名を指定して引数を渡せる言語でもこの課題を緩和できるが、文字が増える

12.2.1 直接的なアプローチ

  • 入力を受け付けられるデータが厳しくなるといろいろな運用の問題が浮かび上がるので、改善する良い機会かも

12.2.2 検出によるアプローチ

  • p.441 誤植: リスト12.4 2番目のリスト isTrue(value -> 0, ...) とあるが、 isTrue(value > 0, ...) の誤りと思われる

12.2.3 新しい API を使ったアプローチ

12.3 ログにおける未検査の文字列

12.3.1 未検査の文字列をログに出力することによる問題

  • p.445 未検査のログ出力、静的解析ツールで検知できないだろうか？

12.3.2 隠れたデータ漏洩の検知

12.4 過保護な実装

12.4.1 コード自体に信頼を置かないコード

  • p.450 リスト12.8 result = true; ではなく return true; のが良い。今のコードだとすべての条件で全件なめてしまう。変数 result もいらない。

12.4.2 契約 (contract) とドメイン・プリミティブを使った解決

  • p.453 誤植: 末尾、 result && ... だと永遠に false が true にならない。 result || ... が正しい。

12.4.3 Optional の過度な利用

12.5 DRY (Don't Repeat Yourself) 原則の誤解

  • p.457 誤植: 3段落目2行目「見つ出すたけめの」→「見つ け 出すための」(け の位置がずれている)

12.5.1 偽陽性 (false positive) による間違った DRY (Don't Repeat Yourself)

12.5.2 重複するテキストを1つにまとめることで起こる問題

  • 日本でよく使う YYYY/MM/DD みたいな日付フォーマットや JST 変換処理などを "DateUtil" みたいにまとめたくなる衝動どうすればいいのか？

    • util でいい派 vs. 共通化しなくていい派で意見が割れる

    • yyyy/MM/dd hh:mm:ss はあまりにもよく使うフォーマットなのでそろそろ標準ライブラリにほしい

    • 営業日扱う処理は・・・ ←それはドメインモデルに落とし込みたいところ

12.5.3 正しい DRY 原則の適用

12.5.4 偽陰性 (false negative)

12.6 ドメイン固有の型における不十分な妥当性確認 (validation)

12.7 テストだけで十分なのか？

12.8 不完全なドメイン・プリミティブ

  • BigDecimal が「少し癖がある」といっているのは、四則演算などが演算子ではなくメソッド呼び出しになっていることだろうか？

    • Java はそろそろ演算子オーバーロードをそろそろ導入しても良いのではなかろうか、 Vector API とかもでてくるし

12.8.1 異なるコンテキストにある通貨

12.8.2 US ドルとスロベニアのトラールの混乱

12.8.3 完結した概念 (conceptual whole) の形成

  • p.472 通貨が異なると例外が出る？

    • isTrue は false の場合 IllegalArgumentException が出る

    • 通貨の切り上げとかの場合は日付も検査しないと？

  • p.472 Money クラスみたいなのが登場すると、それを使うクラスを DB に直接突っ込めなくなる (DB の1カラムとフィールドが 1:1 ではなくなる) ので、マッパーを書いたり DAO を作ったりしなくてはならず、手間は増えるがやるしかない

第13章 マイクロサービスでの指針

13.1 マイクロサービスとは何か？

13.1.1 独立したサービスの実行環境

13.1.2 独立して行えるサービスの更新

13.1.3 停止することを前提としたサービスの設計

13.2 境界づけられたコンテキスト (bounded context) を表すサービス

13.2.1 API の設計の重要性

  • p.482 addConfirmedPayment には CustomerId はいらないのだろうか？

    • ConfirmedPaymentId に顧客を識別する要素も含まれているのかもしれない

    • 反対に addLegalAgreement の AgreementId は契約書の種類の識別ぐらいしかできないのかもしれない

注釈

本日は、 p.483 の 13.2.2 の手前まで