はじめに 設計がしっかりしていないまま開発をしてしまうとビジネスロジックとライブラリが密結合となりがちです。 密結合度が高いほど修正が困難となり、継続的な開発の難易度が上がっていきます。(技術的負債) またプロジェクトが大きくなってくると扱うデータ量も多くなり処理速度もデータ量に比例するため、計算量オーダーの影響を受けます。 プロジェクトのそれぞれの機能に対して 1. 再利用可能 2. テストしやすい 3. 機能追加しやすい 4. ビジネスロジックとライブラリ、REST API(+マスターデータ)を分離できる となっていれば継続的な開発がしやすいです。 最近ではクライアントサイドではクリーンアーキテクチャ、Atomic Design、バックエンドではマイクロサービス化という設計方法があります。 この設計が良いと感じているのはビジネスロジックと機能の責務を分離し、 ライブラリとREST AP
![React(+Redux)+gRPCで実現するクリーンアーキテクチャ+マイクロサービス構成](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cb62efb1a65b5874664aea9442c22ca14a8a8d3/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9UmVhY3QlMjglMkJSZWR1eCUyOSUyQmdSUEMlRTMlODElQTclRTUlQUUlOUYlRTclOEYlQkUlRTMlODElOTklRTMlODIlOEIlRTMlODIlQUYlRTMlODMlQUElRTMlODMlQkMlRTMlODMlQjMlRTMlODIlQTIlRTMlODMlQkMlRTMlODIlQUQlRTMlODMlODYlRTMlODIlQUYlRTMlODMlODElRTMlODMlQTMlRUYlQkMlOEIlRTMlODMlOUUlRTMlODIlQTQlRTMlODIlQUYlRTMlODMlQUQlRTMlODIlQjUlRTMlODMlQkMlRTMlODMlOTMlRTMlODIlQjklRTYlQTclOEIlRTYlODglOTAmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTM4NmE5MjQ3ZjBlOTNhZjdhYTE5ZDQyNGFlNTc5Yjcw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0ZXJhZG9uYnVyaSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MjkwNjYzZjM2NmE3MWU4ODkzYWVlMDNkNDE3M2I1ZWE%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44Of44OE44Oi44Ki%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D0d91cbc14625b4108a48b4e46a9bfa17)