私がコードを書くのをやめ、設計を始めた理由
かつて私は、ソフトウェア開発とは機能を書くことだと思っていました。エンティティを作成し、コントローラーを構築し、データベースを接続するのが自分の仕事だと思っていたのです。
最近のプロジェクトで、その考え方が変わりました。コーディングは解決策の一部に過ぎないということを学んだのです。本当の仕事は、コードを一行も書く前に始まっています。
アーキテクチャを決定しなければなりません。なぜそれが適しているのか、コストはいくらか、そしてどのようなリスクを解決するのかを問い直す必要があります。
私が学んだ主な教訓は以下の通りです：
• アーキテクチャは製品のステージに合わせるべきである。 すぐにマイクロサービスやKubernetes、複雑なイベントキューを使いたくなるものです。しかし私たちのプロジェクトでは、単一プロセス内のレイヤードアーキテクチャを採用しました。これにより、分散システムの煩わしさを避けることなく、責務を分離することができました。立ち上げ時期は、シンプルな方が良いことが多いのです。
• 今は安上がりでも、後で高くつく決定がある。 私たちは初日からデータモデルにTenantIdを追加しました。クライアントは一人しかいませんでしたが、これによって将来のSaaSモデルへの移行が容易になりました。マルチテナンシーの導入を遅らせすぎると、移行作業は悪夢のようなものになります。
• 設計は将来の行き詰まりを防ぐ。 プログラミングは目の前の問題を解決します。設計は、将来の選択肢を狭めることなく問題を解決します。私たちは、異なるインフラへの移行を容易にするために早い段階からコンテナを使用しました。また、プロバイダーの切り替えを簡単にするためにインターフェースを活用しました。
• ビジネスの変化が技術的な変化を促す。 ビジネスが成長することで、システムはマイクロサービスへと移行します。単一のクリニック向けアプリが、数百のクリニック向けのSaaSプラットフォームへと進化するのです。この変化によって、請求、サブスクリプション、スケーリングの扱い方が変わります。
• 信頼性にはスマートなパターンが必要である。 私たちは同期呼び出しからイベント駆動型アーキテクチャへと移行しました。医療システムにおいて、通知サービスの遅延が予約機能のクラッシュを引き起こすべきではありません。メッセージブローカーが故障してもデータが安全に保たれるよう、Outboxパターンを採用しました。
• パターンはドメインに適合させるべきである。 パターンを盲目的に使ってはいけません。医療診断には強い整合性（strong consistency）が必要です。患者の安全を守るために、結果整合性（eventual consistency）に頼ることはできません。監査トレイルを損なう可能性があるなら、機密性の高い臨床データにキャッシュを使用してはいけません。
• DevOpsは後回しにしてはいけない。 デプロイ、ヘルスチェック、パイプラインは、初期設計の一部です。コストを見積もり、実際にニーズを満たすコンポーネントを選択しなければなりません。
プログラマーとデザイナーの違いは、「なぜ」という問いにあります。
プログラマーはこう問いかけます：「これをどうやって動かすか？」 デザイナーはこう問いかけます：「なぜこれが、この特定の問題に対する正しい解決策なのか？」