メインコンテンツまでスキップ

Software Design 202403

DDD​

DDD の概要​

DDD の特徴は、複雑な業務ロジックに焦点を合わせること、モデルに基づいて設計すること、リファクタリングを頻繁に行うことの 3 つ。

業務ルールとは、売り上げ最大化とコスト最小化のために、適切な行動を刺激し、不適切な行動を制限する様々なルールのこと。「事業目標を達成するための行動を統制する決めごと」といえる。一方、業務ロジックは、ソフトウェアそのものや、ソフトウェアとして表現された業務ルールといえる。業務ロジックには単純なものもあるが、DDD では複雑なものに注目する。金を生むのはそちらだし、どんどん複雑になっていくものだから。

業務内容や要求を理解するためのモデルを分析モデル、ソフトウェアを実際に作るためのモデルを設計モデルとよぶ。DDD ではこの 2 つを一致させることに価値を置いている。

戦略的設計は、視野を広げてモデルを作るための設計手法。ユビキタス言語、境界づけられたコンテキスト、コンテキストマップ、コアドメインなど。戦術的設計は、複雑な業務ロジックをソフトウェアで表現するための設計手法。エンティティ、値オブジェクト、集約、モジュール、リポジトリなど。

軽量 DDD とは、いいとこ取りをした DDD を指すのではなく、「複雑な業務ロジックに焦点を当てる」ことを放棄して、小手先の戦術(リポジトリがどうとか)だけを猿まねしたようなものを指す。

(あとはちょっと何言ってるかよく分からん)

ユビキタス言語​

ユビキタス言語を決めるときの Tips

  • 口ずさんでみて違和感がないか
  • あとから重複する可能性のない言葉か
  • あとで変えられるので悩みすぎない
  • どんどん使用を促していく
  • 日本語と英語を両方決める
  • 言葉として綺麗かどうかよりも、チーム内で誤解が生じないかを重視する
  • 頻繁に会話に出てくる言葉のみ定義する（全部やると大変）
  • 視覚的に分かりやすく管理する（ドメインモデル図？）

ドメイン​

リソースレコードとは、DNS において、ドメイン名に関連付けられた情報（レコード）のこと。

  • A レコード
    • IPv4 アドレス
  • AAAA レコード
    • IPv6 アドレス
    • クアッド A レコードと呼ばれる
  • HTTPS レコード
    • A レコードの情報に加えて、使用できる HTTP のプロトコルを返す
    • 2020 年に定義された
  • MX レコード
    • メールサーバを返す
    • 優先順位を設定できる
  • TXT レコード
    • ドメインの所有を証明する際などに使われる
  • CNAME レコード
    • アクセスしているドメインはそのままで、実際の通信先を別のサーバにしたいときに使う
    • CDN や WAF で使う
    • ゾーンアペックスには使えない。もし使いたければ ALIAS レコードが設定できるネームサーバ(Route53 ほか)を使う必要がある。
  • NS レコード
    • サブドメインの権威サーバを別のサーバへ委譲するときに使う
    • 大きな組織でサブドメインごとに業務を分けたいときなどに便利

DNS には権威サーバとキャッシュサーバの 2 種類がある。権威サーバはドメイン所有者が登録したゾーン情報を格納する。キャッシュサーバはその情報をキャッシュするだけである。もしキャッシュサーバにキャッシュがなかった場合の通信の流れは以下のようになる。

  • キャッシュサーバが DNS ルートサーバ（世界に 13 台）へリクエストし、.jpの権威サーバを得る
  • キャッシュサーバから.jpの権威サーバにリクエストし、example.jpの権威サーバを得る
  • キャッシュサーバからexample.jpの権威サーバにリクエストし、目的のリソースレコードを得る

データベースリファクタリング / OR と部分一致​

機能追加に伴い検索フォームはどんどん混沌としていくもの。

SQL で OR 句や部分一致検索(前方一致や後方一致は OK)を使うとインデックスが効かなくなるので、検索など恒常的に使われるようなクエリでは要注意。

OR 句については、クエリを分割して実行した上で UNION 句を使って結合することで、パフォーマンスが改善できる場合がある。メリットはアプリケーションを改修する必要がない点。デメリットはクエリが複雑になる点。

部分一致検索については、全文検索のためのインデックスを作成し、適切なクエリを発行することで解消できる場合がある。手軽に利用できる反面、インデックス作成のコストが大きかったり、複雑な要件には対応できない場合もある。

NoSQL を組み合わせる手もある。複雑な検索が必要な場合は Elasticseatch を、高速なレスポンスが必要な場合は Redis を使う場合が多い。メリットは、アーキテクチャがシンプルになること。デメリットは運用・学習コストの増大、整合性の担保に工夫が必要になる、といった点が挙げられる。

AWS IAM Identity Center (ex. AWS SSO)​

シングルサインオンの機能を提供する。一度の認証(e.g. Google Workspace での認証)により、複数の複数の AWS アカウントを簡単に切り替えて使えるようになる。このサービスを使うと、IAM ユーザーは基本的に不要になる。