河野佳
@fanjia.bsky.social
29.クリーン組込みアーキテクチャ
- ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関係により、ソフトウェアが内部から破壊される可能性がある。
- ファームウェアの定義は、格納される場所ではなく、それが何に依存しているのか、ハードウェアの進化に合わせてどれだけ変化しにくいかで決まる。ソフトウェアとファームウェアの境界線は、存在しないのではないかと思えるほどあいまいなことが多い。
- ファームウェアをあまり書かないようにして、寿命を長くする機会をコードに与える。
- プロセッサ抽象化レイヤーやOS抽象化レイヤーで、低レベル機能やOSからソフトウェアを分離する。
- ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関係により、ソフトウェアが内部から破壊される可能性がある。
- ファームウェアの定義は、格納される場所ではなく、それが何に依存しているのか、ハードウェアの進化に合わせてどれだけ変化しにくいかで決まる。ソフトウェアとファームウェアの境界線は、存在しないのではないかと思えるほどあいまいなことが多い。
- ファームウェアをあまり書かないようにして、寿命を長くする機会をコードに与える。
- プロセッサ抽象化レイヤーやOS抽象化レイヤーで、低レベル機能やOSからソフトウェアを分離する。
May 6, 2025 at 11:38 AM
29.クリーン組込みアーキテクチャ
- ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関係により、ソフトウェアが内部から破壊される可能性がある。
- ファームウェアの定義は、格納される場所ではなく、それが何に依存しているのか、ハードウェアの進化に合わせてどれだけ変化しにくいかで決まる。ソフトウェアとファームウェアの境界線は、存在しないのではないかと思えるほどあいまいなことが多い。
- ファームウェアをあまり書かないようにして、寿命を長くする機会をコードに与える。
- プロセッサ抽象化レイヤーやOS抽象化レイヤーで、低レベル機能やOSからソフトウェアを分離する。
- ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関係により、ソフトウェアが内部から破壊される可能性がある。
- ファームウェアの定義は、格納される場所ではなく、それが何に依存しているのか、ハードウェアの進化に合わせてどれだけ変化しにくいかで決まる。ソフトウェアとファームウェアの境界線は、存在しないのではないかと思えるほどあいまいなことが多い。
- ファームウェアをあまり書かないようにして、寿命を長くする機会をコードに与える。
- プロセッサ抽象化レイヤーやOS抽象化レイヤーで、低レベル機能やOSからソフトウェアを分離する。
28.テスト境界
- テストはアーキテクチャの円の外側にある、テストシステムに独立してデプロイ可能な最も独立したコンポーネントである。
- テストの役割は、開発をサポートすること。
- テストAPIの目的は、UIからテストを切り離すことだけではなく、アプリケーションの構造からテストを切り離すこと。そして、アプリケーションの構造をテストから隠すことが役割。
- テストもうまく設計すべきシステムの一部。システムの一部として設定されていないテストは、脆弱で保守が難しくなる傾向がある。
- テストはアーキテクチャの円の外側にある、テストシステムに独立してデプロイ可能な最も独立したコンポーネントである。
- テストの役割は、開発をサポートすること。
- テストAPIの目的は、UIからテストを切り離すことだけではなく、アプリケーションの構造からテストを切り離すこと。そして、アプリケーションの構造をテストから隠すことが役割。
- テストもうまく設計すべきシステムの一部。システムの一部として設定されていないテストは、脆弱で保守が難しくなる傾向がある。
May 5, 2025 at 9:41 AM
28.テスト境界
- テストはアーキテクチャの円の外側にある、テストシステムに独立してデプロイ可能な最も独立したコンポーネントである。
- テストの役割は、開発をサポートすること。
- テストAPIの目的は、UIからテストを切り離すことだけではなく、アプリケーションの構造からテストを切り離すこと。そして、アプリケーションの構造をテストから隠すことが役割。
- テストもうまく設計すべきシステムの一部。システムの一部として設定されていないテストは、脆弱で保守が難しくなる傾向がある。
- テストはアーキテクチャの円の外側にある、テストシステムに独立してデプロイ可能な最も独立したコンポーネントである。
- テストの役割は、開発をサポートすること。
- テストAPIの目的は、UIからテストを切り離すことだけではなく、アプリケーションの構造からテストを切り離すこと。そして、アプリケーションの構造をテストから隠すことが役割。
- テストもうまく設計すべきシステムの一部。システムの一部として設定されていないテストは、脆弱で保守が難しくなる傾向がある。
27.サービス:あらゆる存在
- サービスはシステムのスケーラビリティや開発の利便性に対しては有用だが、アーキテクチャにおいては重要な要素ではない。アプリケーションの振る舞いに分離する、単なる関数呼び出しにすぎない。
- サービスはモノリシックである必要はなく、SOLIDの原則を使用してサービスを設計し、コンポーネントの構造を与えておけば、サービスに含まれる既存のコンポーネントを変更することなく新しいコンポーネントを追加できる。
- サービスはアーキテクチャの境界に囲まれたひとつのコンポーネント、もしくはアーキテクチャの境界に分割された複数のコンポーネントである。
- サービスはシステムのスケーラビリティや開発の利便性に対しては有用だが、アーキテクチャにおいては重要な要素ではない。アプリケーションの振る舞いに分離する、単なる関数呼び出しにすぎない。
- サービスはモノリシックである必要はなく、SOLIDの原則を使用してサービスを設計し、コンポーネントの構造を与えておけば、サービスに含まれる既存のコンポーネントを変更することなく新しいコンポーネントを追加できる。
- サービスはアーキテクチャの境界に囲まれたひとつのコンポーネント、もしくはアーキテクチャの境界に分割された複数のコンポーネントである。
May 5, 2025 at 8:12 AM
27.サービス:あらゆる存在
- サービスはシステムのスケーラビリティや開発の利便性に対しては有用だが、アーキテクチャにおいては重要な要素ではない。アプリケーションの振る舞いに分離する、単なる関数呼び出しにすぎない。
- サービスはモノリシックである必要はなく、SOLIDの原則を使用してサービスを設計し、コンポーネントの構造を与えておけば、サービスに含まれる既存のコンポーネントを変更することなく新しいコンポーネントを追加できる。
- サービスはアーキテクチャの境界に囲まれたひとつのコンポーネント、もしくはアーキテクチャの境界に分割された複数のコンポーネントである。
- サービスはシステムのスケーラビリティや開発の利便性に対しては有用だが、アーキテクチャにおいては重要な要素ではない。アプリケーションの振る舞いに分離する、単なる関数呼び出しにすぎない。
- サービスはモノリシックである必要はなく、SOLIDの原則を使用してサービスを設計し、コンポーネントの構造を与えておけば、サービスに含まれる既存のコンポーネントを変更することなく新しいコンポーネントを追加できる。
- サービスはアーキテクチャの境界に囲まれたひとつのコンポーネント、もしくはアーキテクチャの境界に分割された複数のコンポーネントである。
26.メインコンポーネント
- メインコンポーネントとは、その他のコンポーネントを作成・調整・監督するコンポーネントのこと。
- 究極的な詳細(最下位レベルの方針)で、システムの最初のエントリーポイントになる。オペレーティングシステム以外に、このコンポーネントに依存しているものはない。
- 初期状態や構成を設定して、外部リソースを集めてアプリケーションの上位レベルの方針に制御を渡すプラグインと考えることもできる。例えば、開発用、テスト用、本番用、デプロイする国別、権限別、顧客別などの設定ごとのメインコンポーネントを持つこともできる。
- メインコンポーネントとは、その他のコンポーネントを作成・調整・監督するコンポーネントのこと。
- 究極的な詳細(最下位レベルの方針)で、システムの最初のエントリーポイントになる。オペレーティングシステム以外に、このコンポーネントに依存しているものはない。
- 初期状態や構成を設定して、外部リソースを集めてアプリケーションの上位レベルの方針に制御を渡すプラグインと考えることもできる。例えば、開発用、テスト用、本番用、デプロイする国別、権限別、顧客別などの設定ごとのメインコンポーネントを持つこともできる。
May 5, 2025 at 6:53 AM
26.メインコンポーネント
- メインコンポーネントとは、その他のコンポーネントを作成・調整・監督するコンポーネントのこと。
- 究極的な詳細(最下位レベルの方針)で、システムの最初のエントリーポイントになる。オペレーティングシステム以外に、このコンポーネントに依存しているものはない。
- 初期状態や構成を設定して、外部リソースを集めてアプリケーションの上位レベルの方針に制御を渡すプラグインと考えることもできる。例えば、開発用、テスト用、本番用、デプロイする国別、権限別、顧客別などの設定ごとのメインコンポーネントを持つこともできる。
- メインコンポーネントとは、その他のコンポーネントを作成・調整・監督するコンポーネントのこと。
- 究極的な詳細(最下位レベルの方針)で、システムの最初のエントリーポイントになる。オペレーティングシステム以外に、このコンポーネントに依存しているものはない。
- 初期状態や構成を設定して、外部リソースを集めてアプリケーションの上位レベルの方針に制御を渡すプラグインと考えることもできる。例えば、開発用、テスト用、本番用、デプロイする国別、権限別、顧客別などの設定ごとのメインコンポーネントを持つこともできる。
25.レイヤーと境界
- アーキテクチャの境界はあらゆるところに存在する。境界を完全に構築しようとするとコストが高くつき、無視しようとするとレイヤーを追加するコストが非常に高くなる。
- 抽象化が必要になることを予測してはいけない(YAGNIの哲学)。アーバーエンジニアリングのほうが、アンダーエンジニアリングよりも悪質である。
- コストを評価し、アーキテクチャの境界がどこにあるか、完全に実装すべきなのか無視した方がいいのか判断する必要がある。これは1回限りではない。常に見張る必要がある。境界を実装するコストと無視するコストを比較検討し、その決定を常に見張り何度も評価する。
- アーキテクチャの境界はあらゆるところに存在する。境界を完全に構築しようとするとコストが高くつき、無視しようとするとレイヤーを追加するコストが非常に高くなる。
- 抽象化が必要になることを予測してはいけない(YAGNIの哲学)。アーバーエンジニアリングのほうが、アンダーエンジニアリングよりも悪質である。
- コストを評価し、アーキテクチャの境界がどこにあるか、完全に実装すべきなのか無視した方がいいのか判断する必要がある。これは1回限りではない。常に見張る必要がある。境界を実装するコストと無視するコストを比較検討し、その決定を常に見張り何度も評価する。
May 4, 2025 at 4:39 AM
25.レイヤーと境界
- アーキテクチャの境界はあらゆるところに存在する。境界を完全に構築しようとするとコストが高くつき、無視しようとするとレイヤーを追加するコストが非常に高くなる。
- 抽象化が必要になることを予測してはいけない(YAGNIの哲学)。アーバーエンジニアリングのほうが、アンダーエンジニアリングよりも悪質である。
- コストを評価し、アーキテクチャの境界がどこにあるか、完全に実装すべきなのか無視した方がいいのか判断する必要がある。これは1回限りではない。常に見張る必要がある。境界を実装するコストと無視するコストを比較検討し、その決定を常に見張り何度も評価する。
- アーキテクチャの境界はあらゆるところに存在する。境界を完全に構築しようとするとコストが高くつき、無視しようとするとレイヤーを追加するコストが非常に高くなる。
- 抽象化が必要になることを予測してはいけない(YAGNIの哲学)。アーバーエンジニアリングのほうが、アンダーエンジニアリングよりも悪質である。
- コストを評価し、アーキテクチャの境界がどこにあるか、完全に実装すべきなのか無視した方がいいのか判断する必要がある。これは1回限りではない。常に見張る必要がある。境界を実装するコストと無視するコストを比較検討し、その決定を常に見張り何度も評価する。
24.部分的な境界
- YAGNI(You aren't Going to Need It:あとで必要になることはない)
- 問題に直面している時、「違反しているが、あとで必要になることもある」と考えて、部分的な境界を設定することがある。
- 独立してコンパイルやデプロイが可能なコンポーネントを準備し、それらを同じコンポーネントにまとめる。
- Strategyパターン(完全な境界にする余地を残した、片方だけの構造)
- Facadeパターン(シンプルな境界)
- これらにはそれぞれコストとメリットがある。完全な境界に至るまでの代理として適切な場合もあるが、うまく設定できなければ劣化していく。
- YAGNI(You aren't Going to Need It:あとで必要になることはない)
- 問題に直面している時、「違反しているが、あとで必要になることもある」と考えて、部分的な境界を設定することがある。
- 独立してコンパイルやデプロイが可能なコンポーネントを準備し、それらを同じコンポーネントにまとめる。
- Strategyパターン(完全な境界にする余地を残した、片方だけの構造)
- Facadeパターン(シンプルな境界)
- これらにはそれぞれコストとメリットがある。完全な境界に至るまでの代理として適切な場合もあるが、うまく設定できなければ劣化していく。
May 4, 2025 at 3:23 AM
24.部分的な境界
- YAGNI(You aren't Going to Need It:あとで必要になることはない)
- 問題に直面している時、「違反しているが、あとで必要になることもある」と考えて、部分的な境界を設定することがある。
- 独立してコンパイルやデプロイが可能なコンポーネントを準備し、それらを同じコンポーネントにまとめる。
- Strategyパターン(完全な境界にする余地を残した、片方だけの構造)
- Facadeパターン(シンプルな境界)
- これらにはそれぞれコストとメリットがある。完全な境界に至るまでの代理として適切な場合もあるが、うまく設定できなければ劣化していく。
- YAGNI(You aren't Going to Need It:あとで必要になることはない)
- 問題に直面している時、「違反しているが、あとで必要になることもある」と考えて、部分的な境界を設定することがある。
- 独立してコンパイルやデプロイが可能なコンポーネントを準備し、それらを同じコンポーネントにまとめる。
- Strategyパターン(完全な境界にする余地を残した、片方だけの構造)
- Facadeパターン(シンプルな境界)
- これらにはそれぞれコストとメリットがある。完全な境界に至るまでの代理として適切な場合もあるが、うまく設定できなければ劣化していく。
23.プレゼンターとHumble Object
- プレゼンターはHumble Objectパターンの一種であり、アーキテクチャの境界の特定と保護に役立つ。
- Humble Objectパターンは、テストしにくい振る舞い(View)とテストしやすい振る舞い(Presenter)を分離するために生み出されたデザインパターン。
- Presenterはアプリケーションからデータを受け取り、適切にフォーマットし、Viewが画面に移動できるようにする。
- アーキテクチャの境界でこのパターンを使用すると、システム全体のテスト容易性が大幅に向上する。
- プレゼンターはHumble Objectパターンの一種であり、アーキテクチャの境界の特定と保護に役立つ。
- Humble Objectパターンは、テストしにくい振る舞い(View)とテストしやすい振る舞い(Presenter)を分離するために生み出されたデザインパターン。
- Presenterはアプリケーションからデータを受け取り、適切にフォーマットし、Viewが画面に移動できるようにする。
- アーキテクチャの境界でこのパターンを使用すると、システム全体のテスト容易性が大幅に向上する。
May 3, 2025 at 2:05 PM
23.プレゼンターとHumble Object
- プレゼンターはHumble Objectパターンの一種であり、アーキテクチャの境界の特定と保護に役立つ。
- Humble Objectパターンは、テストしにくい振る舞い(View)とテストしやすい振る舞い(Presenter)を分離するために生み出されたデザインパターン。
- Presenterはアプリケーションからデータを受け取り、適切にフォーマットし、Viewが画面に移動できるようにする。
- アーキテクチャの境界でこのパターンを使用すると、システム全体のテスト容易性が大幅に向上する。
- プレゼンターはHumble Objectパターンの一種であり、アーキテクチャの境界の特定と保護に役立つ。
- Humble Objectパターンは、テストしにくい振る舞い(View)とテストしやすい振る舞い(Presenter)を分離するために生み出されたデザインパターン。
- Presenterはアプリケーションからデータを受け取り、適切にフォーマットし、Viewが画面に移動できるようにする。
- アーキテクチャの境界でこのパターンを使用すると、システム全体のテスト容易性が大幅に向上する。
22.クリーンアーキテクチャ
- ヘキサゴナルアーキテクチャ、DCIアーキテクチャ、BCEはいずれも「関心事の分離」という同じ目的を持っている。ソフトウェアをレイヤーに分割することで、実現している。
- ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない。円の内側は外側について何も知らない。
- 制御の流れがどのような方向であっても、依存性のルールに違反しないように動的なポリモーフィズムを活用して、例えばユースケースから円の内側にあるプレゼンターのインターフェイスを呼び出すようにして制御の流れとは反対のソースコードの依存関係を生みだす。
- ヘキサゴナルアーキテクチャ、DCIアーキテクチャ、BCEはいずれも「関心事の分離」という同じ目的を持っている。ソフトウェアをレイヤーに分割することで、実現している。
- ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない。円の内側は外側について何も知らない。
- 制御の流れがどのような方向であっても、依存性のルールに違反しないように動的なポリモーフィズムを活用して、例えばユースケースから円の内側にあるプレゼンターのインターフェイスを呼び出すようにして制御の流れとは反対のソースコードの依存関係を生みだす。
May 3, 2025 at 4:57 AM
22.クリーンアーキテクチャ
- ヘキサゴナルアーキテクチャ、DCIアーキテクチャ、BCEはいずれも「関心事の分離」という同じ目的を持っている。ソフトウェアをレイヤーに分割することで、実現している。
- ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない。円の内側は外側について何も知らない。
- 制御の流れがどのような方向であっても、依存性のルールに違反しないように動的なポリモーフィズムを活用して、例えばユースケースから円の内側にあるプレゼンターのインターフェイスを呼び出すようにして制御の流れとは反対のソースコードの依存関係を生みだす。
- ヘキサゴナルアーキテクチャ、DCIアーキテクチャ、BCEはいずれも「関心事の分離」という同じ目的を持っている。ソフトウェアをレイヤーに分割することで、実現している。
- ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない。円の内側は外側について何も知らない。
- 制御の流れがどのような方向であっても、依存性のルールに違反しないように動的なポリモーフィズムを活用して、例えばユースケースから円の内側にあるプレゼンターのインターフェイスを呼び出すようにして制御の流れとは反対のソースコードの依存関係を生みだす。
21.叫ぶアーキテクチャ
- 建物の設計図を見ると、どんな建物であるかが見て分かる。つまり、叫んでいる。
- ソフトウェアアプリケーションのアーキテクチャもシステムのユースケースについて叫ぶべきである。
- 優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、ツール、環境に依存することなく、ユースケースをサポートする構造を問題なく説明できる。
- ウェブは提供の仕組み（IOデバイス）であり、アーキテクチャもそのように扱うべき。システム構造を支配するものではない。
- アーキテクチャはフレームワークから距離を置いたものにし、そのままの状態でテスト可能でなければいけない。
- 建物の設計図を見ると、どんな建物であるかが見て分かる。つまり、叫んでいる。
- ソフトウェアアプリケーションのアーキテクチャもシステムのユースケースについて叫ぶべきである。
- 優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、ツール、環境に依存することなく、ユースケースをサポートする構造を問題なく説明できる。
- ウェブは提供の仕組み（IOデバイス）であり、アーキテクチャもそのように扱うべき。システム構造を支配するものではない。
- アーキテクチャはフレームワークから距離を置いたものにし、そのままの状態でテスト可能でなければいけない。
March 1, 2025 at 7:05 AM
21.叫ぶアーキテクチャ
- 建物の設計図を見ると、どんな建物であるかが見て分かる。つまり、叫んでいる。
- ソフトウェアアプリケーションのアーキテクチャもシステムのユースケースについて叫ぶべきである。
- 優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、ツール、環境に依存することなく、ユースケースをサポートする構造を問題なく説明できる。
- ウェブは提供の仕組み（IOデバイス）であり、アーキテクチャもそのように扱うべき。システム構造を支配するものではない。
- アーキテクチャはフレームワークから距離を置いたものにし、そのままの状態でテスト可能でなければいけない。
- 建物の設計図を見ると、どんな建物であるかが見て分かる。つまり、叫んでいる。
- ソフトウェアアプリケーションのアーキテクチャもシステムのユースケースについて叫ぶべきである。
- 優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、ツール、環境に依存することなく、ユースケースをサポートする構造を問題なく説明できる。
- ウェブは提供の仕組み（IOデバイス）であり、アーキテクチャもそのように扱うべき。システム構造を支配するものではない。
- アーキテクチャはフレームワークから距離を置いたものにし、そのままの状態でテスト可能でなければいけない。
20.ビジネスルール
- ビジネスルールはビジネスマネーを生み出したり節約したりするルールや手続きのこと。ビジネスに欠かせないものを最重要ビジネスルールと呼び、これに必要なデータを最重要ビジネスデータと呼ぶ。
- エンティティとはコンピュータシステムのオブジェクトであり、インターフェイスはそうした最重要ビジネスルールを実装した関数を含む。
- ユースケースとは自動化されたシステムを利用する方法を記述したもの。エンティティとは異なり、アプリケーション固有のビジネスルールを含む。システムの入出力に近い。
- ユースケースはエンティティの最重要ビジネスルールをいつ、どのように呼び出すかを規定する。
- ビジネスルールはビジネスマネーを生み出したり節約したりするルールや手続きのこと。ビジネスに欠かせないものを最重要ビジネスルールと呼び、これに必要なデータを最重要ビジネスデータと呼ぶ。
- エンティティとはコンピュータシステムのオブジェクトであり、インターフェイスはそうした最重要ビジネスルールを実装した関数を含む。
- ユースケースとは自動化されたシステムを利用する方法を記述したもの。エンティティとは異なり、アプリケーション固有のビジネスルールを含む。システムの入出力に近い。
- ユースケースはエンティティの最重要ビジネスルールをいつ、どのように呼び出すかを規定する。
February 22, 2025 at 7:56 AM
20.ビジネスルール
- ビジネスルールはビジネスマネーを生み出したり節約したりするルールや手続きのこと。ビジネスに欠かせないものを最重要ビジネスルールと呼び、これに必要なデータを最重要ビジネスデータと呼ぶ。
- エンティティとはコンピュータシステムのオブジェクトであり、インターフェイスはそうした最重要ビジネスルールを実装した関数を含む。
- ユースケースとは自動化されたシステムを利用する方法を記述したもの。エンティティとは異なり、アプリケーション固有のビジネスルールを含む。システムの入出力に近い。
- ユースケースはエンティティの最重要ビジネスルールをいつ、どのように呼び出すかを規定する。
- ビジネスルールはビジネスマネーを生み出したり節約したりするルールや手続きのこと。ビジネスに欠かせないものを最重要ビジネスルールと呼び、これに必要なデータを最重要ビジネスデータと呼ぶ。
- エンティティとはコンピュータシステムのオブジェクトであり、インターフェイスはそうした最重要ビジネスルールを実装した関数を含む。
- ユースケースとは自動化されたシステムを利用する方法を記述したもの。エンティティとは異なり、アプリケーション固有のビジネスルールを含む。システムの入出力に近い。
- ユースケースはエンティティの最重要ビジネスルールをいつ、どのように呼び出すかを規定する。
19.方針とレベル
- ソフトウェアシステムは方針を示したもの。コンピュータプログラムは入力を出力に変換する方針を記述したもので、方針はさらに小さく分割される。
- 同じ理由や時期に変更する方針は同じレベルのコンポーネントにまとめ、下位レベルのコンポーネントが上位レベルに依存するように設計する。
- 「レベル」とは入出力との距離。入出力を管理する方針は最下位レベルになり、そこから離れていればレベルが高くなる。
- 上位レベルの方針は、下位レベルより変更の頻度が低く、変更の理由が重要になる。下位レベルに重要ではないが、緊急の変更があったとしても、上位レベルにはほとんどあるいは全く影響を与えない。
- ソフトウェアシステムは方針を示したもの。コンピュータプログラムは入力を出力に変換する方針を記述したもので、方針はさらに小さく分割される。
- 同じ理由や時期に変更する方針は同じレベルのコンポーネントにまとめ、下位レベルのコンポーネントが上位レベルに依存するように設計する。
- 「レベル」とは入出力との距離。入出力を管理する方針は最下位レベルになり、そこから離れていればレベルが高くなる。
- 上位レベルの方針は、下位レベルより変更の頻度が低く、変更の理由が重要になる。下位レベルに重要ではないが、緊急の変更があったとしても、上位レベルにはほとんどあるいは全く影響を与えない。
February 22, 2025 at 4:56 AM
19.方針とレベル
- ソフトウェアシステムは方針を示したもの。コンピュータプログラムは入力を出力に変換する方針を記述したもので、方針はさらに小さく分割される。
- 同じ理由や時期に変更する方針は同じレベルのコンポーネントにまとめ、下位レベルのコンポーネントが上位レベルに依存するように設計する。
- 「レベル」とは入出力との距離。入出力を管理する方針は最下位レベルになり、そこから離れていればレベルが高くなる。
- 上位レベルの方針は、下位レベルより変更の頻度が低く、変更の理由が重要になる。下位レベルに重要ではないが、緊急の変更があったとしても、上位レベルにはほとんどあるいは全く影響を与えない。
- ソフトウェアシステムは方針を示したもの。コンピュータプログラムは入力を出力に変換する方針を記述したもので、方針はさらに小さく分割される。
- 同じ理由や時期に変更する方針は同じレベルのコンポーネントにまとめ、下位レベルのコンポーネントが上位レベルに依存するように設計する。
- 「レベル」とは入出力との距離。入出力を管理する方針は最下位レベルになり、そこから離れていればレベルが高くなる。
- 上位レベルの方針は、下位レベルより変更の頻度が低く、変更の理由が重要になる。下位レベルに重要ではないが、緊急の変更があったとしても、上位レベルにはほとんどあるいは全く影響を与えない。
18.境界の解剖学
- 境界の向こう側にある関数呼び出しやデータの受け渡しで、適切に境界を越えるにはソースコードの依存関係を管理する必要がある。
- 下位レベルのクライアントから上位レベルのサービスに対して関数呼出しする。上位レベルのクライアントが下位レベルのサービスを呼び出す場合、制御の流れの依存性の逆転させる。
- アーキテクチャの目標は、下位レベルのプロセスまたはサービスを上位レベルのプロセスまたはサービスのプラグインにすること。
- 境界戦略にはモノリス、デプロイコンポーネント、スレッド、ローカルプロセス、サービスがある。モノリス以外のほとんどのシステムで、複数の境界戦略を使用する。
- 境界の向こう側にある関数呼び出しやデータの受け渡しで、適切に境界を越えるにはソースコードの依存関係を管理する必要がある。
- 下位レベルのクライアントから上位レベルのサービスに対して関数呼出しする。上位レベルのクライアントが下位レベルのサービスを呼び出す場合、制御の流れの依存性の逆転させる。
- アーキテクチャの目標は、下位レベルのプロセスまたはサービスを上位レベルのプロセスまたはサービスのプラグインにすること。
- 境界戦略にはモノリス、デプロイコンポーネント、スレッド、ローカルプロセス、サービスがある。モノリス以外のほとんどのシステムで、複数の境界戦略を使用する。
February 15, 2025 at 2:35 PM
18.境界の解剖学
- 境界の向こう側にある関数呼び出しやデータの受け渡しで、適切に境界を越えるにはソースコードの依存関係を管理する必要がある。
- 下位レベルのクライアントから上位レベルのサービスに対して関数呼出しする。上位レベルのクライアントが下位レベルのサービスを呼び出す場合、制御の流れの依存性の逆転させる。
- アーキテクチャの目標は、下位レベルのプロセスまたはサービスを上位レベルのプロセスまたはサービスのプラグインにすること。
- 境界戦略にはモノリス、デプロイコンポーネント、スレッド、ローカルプロセス、サービスがある。モノリス以外のほとんどのシステムで、複数の境界戦略を使用する。
- 境界の向こう側にある関数呼び出しやデータの受け渡しで、適切に境界を越えるにはソースコードの依存関係を管理する必要がある。
- 下位レベルのクライアントから上位レベルのサービスに対して関数呼出しする。上位レベルのクライアントが下位レベルのサービスを呼び出す場合、制御の流れの依存性の逆転させる。
- アーキテクチャの目標は、下位レベルのプロセスまたはサービスを上位レベルのプロセスまたはサービスのプラグインにすること。
- 境界戦略にはモノリス、デプロイコンポーネント、スレッド、ローカルプロセス、サービスがある。モノリス以外のほとんどのシステムで、複数の境界戦略を使用する。
17.バウンダリー:境界線を引く
- 初期に境界線を引くのは、決定を遅くし、それによりビジネスロジックが汚染されないようにするため。この決定とは、システムのビジネス要件（ユースケース）と関係のないフレームワークやDB、ウェブサーバーなどを指す。
- 境界線は「重要なもの」と「重要ではないもの」の間、変更の軸のあるところに引く。GUIはビジネスルールと異なる時間や頻度で変更され、ビジネスルールはDIフレームワークと異なる時間や理由で変更される。
- UIやDBをプラグインとして扱えば、異なるユーザーインターフェースや異なるDBに置き換えることが可能になる。
- 初期に境界線を引くのは、決定を遅くし、それによりビジネスロジックが汚染されないようにするため。この決定とは、システムのビジネス要件（ユースケース）と関係のないフレームワークやDB、ウェブサーバーなどを指す。
- 境界線は「重要なもの」と「重要ではないもの」の間、変更の軸のあるところに引く。GUIはビジネスルールと異なる時間や頻度で変更され、ビジネスルールはDIフレームワークと異なる時間や理由で変更される。
- UIやDBをプラグインとして扱えば、異なるユーザーインターフェースや異なるDBに置き換えることが可能になる。
February 15, 2025 at 12:24 PM
17.バウンダリー:境界線を引く
- 初期に境界線を引くのは、決定を遅くし、それによりビジネスロジックが汚染されないようにするため。この決定とは、システムのビジネス要件（ユースケース）と関係のないフレームワークやDB、ウェブサーバーなどを指す。
- 境界線は「重要なもの」と「重要ではないもの」の間、変更の軸のあるところに引く。GUIはビジネスルールと異なる時間や頻度で変更され、ビジネスルールはDIフレームワークと異なる時間や理由で変更される。
- UIやDBをプラグインとして扱えば、異なるユーザーインターフェースや異なるDBに置き換えることが可能になる。
- 初期に境界線を引くのは、決定を遅くし、それによりビジネスロジックが汚染されないようにするため。この決定とは、システムのビジネス要件（ユースケース）と関係のないフレームワークやDB、ウェブサーバーなどを指す。
- 境界線は「重要なもの」と「重要ではないもの」の間、変更の軸のあるところに引く。GUIはビジネスルールと異なる時間や頻度で変更され、ビジネスルールはDIフレームワークと異なる時間や理由で変更される。
- UIやDBをプラグインとして扱えば、異なるユーザーインターフェースや異なるDBに置き換えることが可能になる。
16.独立性
- 最も重要なことは、アーキテクチャレベルでシステムの意図が分かるように振る舞いを明らかにすること。
- 単一責任の原則や閉鎖性共通の原則を使用して、異なる理由で変更されるものを分離し、同じ理由で変更されるものをまとめることができる。
- システムをコンポーネントに適切に分割すれば、システムの運用ニーズの変化に合わせて比較的簡単に移行することができる。
- 優れたアーキテクチャは、ソースコードを変更から保護してくれる。切り離し方式を選択肢として残すことで、大規模なデプロイと小規模なデプロイで使用する方式を変えることができる。
- 最も重要なことは、アーキテクチャレベルでシステムの意図が分かるように振る舞いを明らかにすること。
- 単一責任の原則や閉鎖性共通の原則を使用して、異なる理由で変更されるものを分離し、同じ理由で変更されるものをまとめることができる。
- システムをコンポーネントに適切に分割すれば、システムの運用ニーズの変化に合わせて比較的簡単に移行することができる。
- 優れたアーキテクチャは、ソースコードを変更から保護してくれる。切り離し方式を選択肢として残すことで、大規模なデプロイと小規模なデプロイで使用する方式を変えることができる。
February 15, 2025 at 7:21 AM
16.独立性
- 最も重要なことは、アーキテクチャレベルでシステムの意図が分かるように振る舞いを明らかにすること。
- 単一責任の原則や閉鎖性共通の原則を使用して、異なる理由で変更されるものを分離し、同じ理由で変更されるものをまとめることができる。
- システムをコンポーネントに適切に分割すれば、システムの運用ニーズの変化に合わせて比較的簡単に移行することができる。
- 優れたアーキテクチャは、ソースコードを変更から保護してくれる。切り離し方式を選択肢として残すことで、大規模なデプロイと小規模なデプロイで使用する方式を変えることができる。
- 最も重要なことは、アーキテクチャレベルでシステムの意図が分かるように振る舞いを明らかにすること。
- 単一責任の原則や閉鎖性共通の原則を使用して、異なる理由で変更されるものを分離し、同じ理由で変更されるものをまとめることができる。
- システムをコンポーネントに適切に分割すれば、システムの運用ニーズの変化に合わせて比較的簡単に移行することができる。
- 優れたアーキテクチャは、ソースコードを変更から保護してくれる。切り離し方式を選択肢として残すことで、大規模なデプロイと小規模なデプロイで使用する方式を変えることができる。
15.アーキテクチャとは
- ソフトウェアシステムのアーキテクチャとは、システムに与えた「形状」。形状の目的はソフトウェアシステムの開発・デプロイ・運用・保守を容易にし、プログラマの生産性を最大にすること。
- チームの構成が異なれば、アーキテクチャの決定は異なる。
- ソフトウェアが開発されたのは、マシンの振る舞いをすばやく変更するため。
- アーキテクトは方針と詳細を区別し、方針をシステムの最も重要と認識するシステムの形状にデザインし、詳細の選択肢をできるだけ多く残す。選択肢を残せる期間が長ければ、実験できることが増え、決定しなければいけない時点までに入手できる情報も増える。
- ソフトウェアシステムのアーキテクチャとは、システムに与えた「形状」。形状の目的はソフトウェアシステムの開発・デプロイ・運用・保守を容易にし、プログラマの生産性を最大にすること。
- チームの構成が異なれば、アーキテクチャの決定は異なる。
- ソフトウェアが開発されたのは、マシンの振る舞いをすばやく変更するため。
- アーキテクトは方針と詳細を区別し、方針をシステムの最も重要と認識するシステムの形状にデザインし、詳細の選択肢をできるだけ多く残す。選択肢を残せる期間が長ければ、実験できることが増え、決定しなければいけない時点までに入手できる情報も増える。
February 11, 2025 at 4:21 AM
15.アーキテクチャとは
- ソフトウェアシステムのアーキテクチャとは、システムに与えた「形状」。形状の目的はソフトウェアシステムの開発・デプロイ・運用・保守を容易にし、プログラマの生産性を最大にすること。
- チームの構成が異なれば、アーキテクチャの決定は異なる。
- ソフトウェアが開発されたのは、マシンの振る舞いをすばやく変更するため。
- アーキテクトは方針と詳細を区別し、方針をシステムの最も重要と認識するシステムの形状にデザインし、詳細の選択肢をできるだけ多く残す。選択肢を残せる期間が長ければ、実験できることが増え、決定しなければいけない時点までに入手できる情報も増える。
- ソフトウェアシステムのアーキテクチャとは、システムに与えた「形状」。形状の目的はソフトウェアシステムの開発・デプロイ・運用・保守を容易にし、プログラマの生産性を最大にすること。
- チームの構成が異なれば、アーキテクチャの決定は異なる。
- ソフトウェアが開発されたのは、マシンの振る舞いをすばやく変更するため。
- アーキテクトは方針と詳細を区別し、方針をシステムの最も重要と認識するシステムの形状にデザインし、詳細の選択肢をできるだけ多く残す。選択肢を残せる期間が長ければ、実験できることが増え、決定しなければいけない時点までに入手できる情報も増える。
14.コンポーネントの結合
- 非循環依存関係の原則(ADP)…コンポーネントの依存グラフに循環依存があってはいけない。循環依存があると、コンポーネントを切り離すのが難しくなる。
- 依存構造はシステムの論理設計に合わせて育てていく。
- 安定依存の原則(SDP)…安定度の高い方向に依存すること。安定度が高い=多数のコンポーネントから依存されている。少し変更するだけで多数のコンポーネントに影響を与える。
- 安定度・抽象度等価の原則(SAP)…コンポーネントの抽象度は、その安定度と同程度でなければならない。安定度が高い→抽象度も高くあるべき。安定度が低い→具体的なものであるべき。
- 非循環依存関係の原則(ADP)…コンポーネントの依存グラフに循環依存があってはいけない。循環依存があると、コンポーネントを切り離すのが難しくなる。
- 依存構造はシステムの論理設計に合わせて育てていく。
- 安定依存の原則(SDP)…安定度の高い方向に依存すること。安定度が高い=多数のコンポーネントから依存されている。少し変更するだけで多数のコンポーネントに影響を与える。
- 安定度・抽象度等価の原則(SAP)…コンポーネントの抽象度は、その安定度と同程度でなければならない。安定度が高い→抽象度も高くあるべき。安定度が低い→具体的なものであるべき。
January 26, 2025 at 6:52 AM
14.コンポーネントの結合
- 非循環依存関係の原則(ADP)…コンポーネントの依存グラフに循環依存があってはいけない。循環依存があると、コンポーネントを切り離すのが難しくなる。
- 依存構造はシステムの論理設計に合わせて育てていく。
- 安定依存の原則(SDP)…安定度の高い方向に依存すること。安定度が高い=多数のコンポーネントから依存されている。少し変更するだけで多数のコンポーネントに影響を与える。
- 安定度・抽象度等価の原則(SAP)…コンポーネントの抽象度は、その安定度と同程度でなければならない。安定度が高い→抽象度も高くあるべき。安定度が低い→具体的なものであるべき。
- 非循環依存関係の原則(ADP)…コンポーネントの依存グラフに循環依存があってはいけない。循環依存があると、コンポーネントを切り離すのが難しくなる。
- 依存構造はシステムの論理設計に合わせて育てていく。
- 安定依存の原則(SDP)…安定度の高い方向に依存すること。安定度が高い=多数のコンポーネントから依存されている。少し変更するだけで多数のコンポーネントに影響を与える。
- 安定度・抽象度等価の原則(SAP)…コンポーネントの抽象度は、その安定度と同程度でなければならない。安定度が高い→抽象度も高くあるべき。安定度が低い→具体的なものであるべき。
初リリース作業立ち会っていただけたの一生感謝してます！🥹
とはいえ立場が変わると考える必要のあることも増えますしね 私もそうならないように心掛けしとこう
とはいえ立場が変わると考える必要のあることも増えますしね 私もそうならないように心掛けしとこう
December 13, 2024 at 4:05 AM
初リリース作業立ち会っていただけたの一生感謝してます！🥹
とはいえ立場が変わると考える必要のあることも増えますしね 私もそうならないように心掛けしとこう
とはいえ立場が変わると考える必要のあることも増えますしね 私もそうならないように心掛けしとこう
実はわりとこれで限界を感じてチーム異動しました😢
December 13, 2024 at 3:35 AM
実はわりとこれで限界を感じてチーム異動しました😢
13.コンポーネントの凝集性
- 再利用・リリース等価の原則(REP)…テーマや目的があり、それを共有するモジュールを集めよという原則。
- 閉鎖性共通の原則(CCP)…変更の理由やタイミングで変更されるクラスをまとめよ、逆に異なるクラスは分けよという原則。単一責任の原則をコンポーネント向けに言い換えたもの。
- 全再利用の原則(CRP)…一緒に用いられることが多いクラスやモジュールはまとめよという原則。密結合していないクラスをまとめるべきではない。
- これらには相反するところがある。利便性と再利用性のトレードオフを考慮しバランスをとる必要がある。
- 最適な落としどころは常に変わり続ける。
- 再利用・リリース等価の原則(REP)…テーマや目的があり、それを共有するモジュールを集めよという原則。
- 閉鎖性共通の原則(CCP)…変更の理由やタイミングで変更されるクラスをまとめよ、逆に異なるクラスは分けよという原則。単一責任の原則をコンポーネント向けに言い換えたもの。
- 全再利用の原則(CRP)…一緒に用いられることが多いクラスやモジュールはまとめよという原則。密結合していないクラスをまとめるべきではない。
- これらには相反するところがある。利便性と再利用性のトレードオフを考慮しバランスをとる必要がある。
- 最適な落としどころは常に変わり続ける。
December 8, 2024 at 7:40 AM
13.コンポーネントの凝集性
- 再利用・リリース等価の原則(REP)…テーマや目的があり、それを共有するモジュールを集めよという原則。
- 閉鎖性共通の原則(CCP)…変更の理由やタイミングで変更されるクラスをまとめよ、逆に異なるクラスは分けよという原則。単一責任の原則をコンポーネント向けに言い換えたもの。
- 全再利用の原則(CRP)…一緒に用いられることが多いクラスやモジュールはまとめよという原則。密結合していないクラスをまとめるべきではない。
- これらには相反するところがある。利便性と再利用性のトレードオフを考慮しバランスをとる必要がある。
- 最適な落としどころは常に変わり続ける。
- 再利用・リリース等価の原則(REP)…テーマや目的があり、それを共有するモジュールを集めよという原則。
- 閉鎖性共通の原則(CCP)…変更の理由やタイミングで変更されるクラスをまとめよ、逆に異なるクラスは分けよという原則。単一責任の原則をコンポーネント向けに言い換えたもの。
- 全再利用の原則(CRP)…一緒に用いられることが多いクラスやモジュールはまとめよという原則。密結合していないクラスをまとめるべきではない。
- これらには相反するところがある。利便性と再利用性のトレードオフを考慮しバランスをとる必要がある。
- 最適な落としどころは常に変わり続ける。