アーキテクチャ設計

軽量DDDやレイヤー設計、データモデリングなど、保守性・拡張性を意識したシステム設計の考え方を解説します。

10件の記事

共通関数に呼び出し元ごとの分岐を継ぎ足していくと何が起きるか

正しく共通化された関数でも、呼び出し元ごとの都合をif分岐で継ぎ足し続けると徐々に壊れていきます。境界を越えた誤った共通化とは異なる、時間経過で起きる腐敗パターンとその直し方を整理します。

メール送信は開発中と本番、あるいは導入先の事情によってプロバイダーが変わりやすい処理です。呼び出し元がプロバイダーの違いを意識しなくて済む抽象化と、2026年7月時点でCloudflare WorkersからSMTP送信が可能になった実装事情を整理します。

DRY原則は「同じコードを2回書くな」という意味で語られがちですが、本来は「1つの業務知識に1つの真実の情報源を」というルールです。割引計算を例に、境界づけられたコンテキストをまたいだ「見た目だけ同じ」処理を共通化する危険性を整理します。

業務ロジックをそのまま実装し、重複が目立ってきたら共通関数に切り出す——これは開発速度は速いですが保守性の低いコードを生みがちです。帳票出力を例に、「呼び出し元がまだ1つでも、外部公開するライブラリだと仮定して設計する」基準がどこで効くかを整理します。

Reactの関数コンポーネントは「状態を外部に持ち、DOM操作を隠蔽する」ことを前提にした設計です。ノードをドラッグして線でつなぐビジュアルエディタを例に、UIライブラリ自体を作る場面ではオブジェクト指向のクラス継承の方が噛み合う理由をコードで比較します。

以前の記事で紹介した軽量DDDは、TypeScriptでは「規約とレビュー」に頼る部分が残ります。関数型言語であるF#の判別共用体・Result型を例に、同じ設計思想がどこまで型システムだけで強制できるかを比較します。

Zod・DBスキーマ・ドメイン層はそれぞれ別の問いに答えるためのものです。型検証を通過した値を、あえてサーバー側で使わず再計算するという実装例から、バリデーションの責務分担を整理します。

「監査要件があるなら論理削除」という定石をそのまま採用しがちですが、テーブルごとに要件を分解すると、物理削除だけで成立させられるケースは意外と多くあります。判断基準を実装例とともに整理します。

フルスケールのDDDは中小規模の業務システム開発には過剰になりがちです。Alcogyが実践する「軽量DDD」の考え方と、集約・リポジトリをどこまで簡略化しているかを解説します。

Drizzle ORMのスキーマ定義はそのままドメインモデルにはなりません。型安全性を活かしつつ、テーブル設計とビジネスロジックの責務をどう分離しているかを実例で説明します。