Webアプリケーション開発では、データベースとの連携が欠かせません。ユーザー情報、商品情報、注文履歴、投稿データ、決済情報、ログデータなど、多くのアプリケーションは何らかの形でデータを保存し、検索し、更新し、削除します。そのため、バックエンド開発ではデータベース操作をどのように安全かつ効率的に扱うかが重要なテーマになります。

SQLを直接記述する方法は柔軟で強力ですが、アプリケーションの規模が大きくなると、型安全性、保守性、記述量、スキーマ変更への対応、チーム内での実装統一などに課題が出てきます。特にTypeScriptを使った開発では、データベースの構造とアプリケーション側の型定義がずれてしまうと、実行時エラーや予期しない不具合につながる可能性があります。

Prismaは、Node.jsとTypeScript向けに利用される次世代ORMです。データモデルをPrisma Schemaで定義し、そこから型安全なPrisma Clientを自動生成することで、データベース操作を直感的かつ安全に行えるようにします。クエリの自動補完や型推論が効くため、開発体験が高く、モダンなバックエンド開発で広く採用されています。

ソフトウェアアーキテクチャは、単に利用するフレームワーク、データベース、クラウドサービス、フォルダ構成を決めるためのものではありません。本来のアーキテクチャは、そのアプリケーションが何を目的としているのか、どのような業務課題を解決するのか、どのような価値を提供するのかを構造から理解できるものであるべきです。コードを見たときに、最初に技術スタックだけが目立つのではなく、ビジネスの目的や主要なユースケースが伝わる構造になっていることが理想です。

叫ぶアーキテクチャは、この考え方を端的に表した設計思想です。英語ではScreaming Architectureと呼ばれ、ロバート・C・マーティン、通称Uncle Bobによって広く知られるようになりました。この思想では、アプリケーションの構造は「このシステムは何のためのものか」を叫ぶべきだと考えます。つまり、フォルダ構成やモジュール構成を見たときに、フレームワーク名や技術層ではなく、業務機能やドメインの意味が読み取れるべきだということです。

オブジェクト指向設計では、データと振る舞いを一緒に管理することが重要です。オブジェクトは単なるデータの入れ物ではなく、自分の状態を持ち、その状態に基づいて適切な処理を実行する存在として設計されます。しかし実務では、オブジェクトから値を取得し、その値を外部のクラスや関数で判定して処理する実装が多く見られます。このような設計では、ロジックがオブジェクトの外側に散らばり、保守性が低下しやすくなります。

Tell, Don't Askは、このような設計上の問題を改善するための原則です。直訳すると「尋ねるのではなく、命じる」という意味であり、オブジェクトの内部状態を外部から取得して判断するのではなく、オブジェクト自身に処理を依頼するべきだという考え方を示します。これはカプセル化、責務分離、保守性向上と深く関係する重要な設計原則です。

本記事では、Tell, Don't Askの基本概念、TellとAskの違い、なぜこの原則が必要なのか、オブジェクト指向設計との関係、Ask中心設計が抱える問題、Tell中心設計がもたらす効果、Feature EnvyやAnemic Domain Modelとの関係、Law of DemeterやSOLID原則とのつながりまで体系的に解説します。

ソフトウェア開発では、機能を素早く実装するだけでなく、長期的に保守しやすく、変更に強い構造を作ることが重要です。特に業務システムやSaaS、長期運用されるWebアプリケーションでは、要件変更、技術変更、外部サービス変更、データベース変更などが継続的に発生します。そのため、ビジネスロジックが特定のフレームワークやデータベース、外部APIに強く依存していると、変更のたびに大きな修正が必要になります。

このような課題に対して有効な設計思想の一つが、オニオンアーキテクチャです。オニオンアーキテクチャは、ドメインモデルをシステムの中心に置き、依存関係を常に内側へ向けるアーキテクチャパターンです。外側にはデータベース、UI、外部サービス、フレームワークなどの技術的な実装を配置し、中心にあるビジネスルールがそれらに依存しないように設計します。

オニオンアーキテクチャでは、システムを同心円状の層として考えます。中心にはドメイン層があり、その外側にアプリケーション層、さらに外側にインフラ層やプレゼンテーション層が配置されます。重要なのは、外側の層は内側の層を知ってよいが、内側の層は外側の層を知らないという依存関係ルールです。このルールによって、ビジネスロジックを技術的な詳細から守ることができます。

ソフトウェア開発では、同じデータの組み合わせが複数のメソッド、クラス、処理フローの中で繰り返し登場することがあります。たとえば、firstName と lastName、zipCode と address、startDate と endDate のように、常に一緒に扱われるデータが別々の引数やフィールドとして何度も現れる場合があります。一見すると単なるデータの並びに見えるかもしれませんが、これは設計上の改善ポイントを示している可能性があります。

このような状態は、コードスメルの一種として「データのかたまり」と呼ばれます。データのかたまりは、関連性の強いデータがオブジェクトとして表現されず、バラバラの値として扱われ続けている状態を示します。すぐにバグを引き起こすとは限りませんが、放置すると引数の肥大化、修正漏れ、重複ロジック、可読性低下、ドメイン知識の欠落といった問題につながります。

ソフトウェアは一度作って終わりではなく、リリース後も継続的に変更され続けます。要件変更、外部サービスの仕様変更、技術スタックの変更、ビジネスルールの追加、パフォーマンス改善、セキュリティ対応など、さまざまな理由でコードは修正されます。そのため、ソフトウェア設計では「今動くこと」だけでなく、「将来の変更にどれだけ耐えられるか」を考えることが非常に重要です。

変化に弱い設計では、1つの仕様変更が多くのクラスやモジュールに影響し、修正コストやテストコストが大きくなります。また、影響範囲が広がるほど、不具合の混入リスクも高まります。特に長期運用される業務システム、Webアプリケーション、SaaS、マイクロサービスでは、変更に強い設計を作ることが保守性と開発速度を維持する鍵になります。

このような課題に対して有効な考え方が、保護された変更点です。保護された変更点は、変化しやすい部分を特定し、その変化がシステム全体に広がらないように保護する設計原則です。GRASPパターンの一つとして知られており、責務設計、抽象化、インターフェース、ポリモーフィズム、依存関係の管理と深く関係しています。

業務システム開発では、単に画面やデータベースを作るだけでなく、業務上のルールや判断基準をどのようにソフトウェア上で表現するかが非常に重要です。注文、請求、在庫、契約、承認、ユーザー権限など、業務には多くのルールが存在します。これらのルールを適切に設計できていないと、機能追加のたびに条件分岐が増え、ロジックが分散し、保守が難しいシステムになってしまいます。

このような業務ルールやドメイン知識を整理し、ソフトウェア上で表現するための考え方がドメインモデルです。ドメインモデルは、ビジネス領域の概念やルールをコード上のモデルとして表現し、システムの中心に据える設計手法です。特に複雑な業務システムでは、ドメインモデルの設計品質が、システム全体の保守性や拡張性に大きく影響します。

ドメインモデルを考えるうえでよく議論されるのが、リッチドメインモデルと貧血ドメインモデルの違いです。リッチドメインモデルは、データと振る舞いを同じモデル内に持たせる設計スタイルです。一方、貧血ドメインモデルは、モデルをデータ入れ物として扱い、業務ロジックをサービス層など外部に置く設計スタイルです。どちらにもメリットとデメリットがあり、プロジェクトの規模や業務ルールの複雑さによって適切な選択は変わります。

ソフトウェアの保守性や拡張性は、コードの見た目だけでなく、モジュール同士の依存関係によって大きく左右されます。どれだけ個々のクラスや関数が整理されていても、モジュール間の依存が複雑に絡み合っていると、変更の影響範囲が広がり、テストやリリースの難易度が高くなります。特に大規模なシステムでは、依存関係の管理が設計品質を決める重要な要素になります。

依存関係を適切に管理するためには、感覚だけで「このモジュールは複雑そう」「このパッケージは危険そう」と判断するのではなく、客観的な指標を使って可視化することが重要です。求心性結合と遠心性結合は、モジュールやパッケージがどのように依存され、どのように外部へ依存しているかを測定するための代表的な指標です。

求心性結合は、あるモジュールが外部からどれだけ依存されているかを示します。一方、遠心性結合は、あるモジュールが外部のモジュールへどれだけ依存しているかを示します。この2つの指標を組み合わせることで、モジュールの安定性、不安定性、変更リスク、アーキテクチャ上の役割を分析できます。

ソフトウェア品質は、開発効率、保守性、信頼性、リリース速度に大きな影響を与える重要な要素です。機能が正しく動作していても、コードが複雑で読みにくく、変更のたびに不具合が発生するような状態では、長期的な開発効率は大きく低下します。特に長期運用されるシステムでは、コード品質の劣化が技術的負債として蓄積し、将来的な開発コストを押し上げる原因になります。

しかし、コード品質は感覚だけで判断すると問題の発見が遅れることがあります。「読みづらい」「複雑そう」「保守しにくい」といった印象は重要ですが、チーム全体で品質を管理するには、客観的な指標も必要です。そこで活用されるのがコード品質指標です。コード品質指標は、コードの複雑さ、保守性、テスト状況、重複、変更頻度、設計上の結合度などを数値や傾向として可視化するための指標群です。

コード品質指標を活用すれば、問題のあるコードを早期に発見し、リファクタリングやテスト強化の優先順位を決めやすくなります。また、静的解析ツールや継続的統合環境と組み合わせることで、品質を継続的に監視し、開発フローの中で自然に改善活動を行うことができます。

Webアプリケーション開発では、機能追加のスピードが速くなる一方で、品質保証の重要性も高まっています。画面表示、フォーム入力、画面遷移、アプリケーション連携仕様、認証処理など、利用者が実際に操作する範囲を正しく検証できなければ、リリース後に重大な不具合が発生する可能性があります。そのため、現代の開発現場では、手動確認だけに頼らず、テスト自動化を取り入れることが重要になっています。

特にエンドツーエンドテストは、利用者に近い視点でWebアプリケーション全体の動作を確認できるため、品質保証において大きな役割を持ちます。しかし、従来のエンドツーエンドテストは、実行が遅い、不安定になりやすい、保守が難しいといった課題を抱えることも少なくありませんでした。画面の読み込み待ちや要素の表示タイミングによってテストが失敗するなど、テストそのものの安定性が問題になるケースもあります。

Playwrightは、こうした課題を解決するために利用されるモダンなブラウザ自動化ツールです。高速で安定したテスト実行、複数ブラウザへの対応、自動待機機能、テストランナー、レポート機能などを備えており、Webアプリケーションの品質保証を効率化できます。継続的統合・継続的デリバリー環境とも連携しやすく、現代的な開発フローに適したテストツールとして注目されています。