持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
@nrslibのマイページ - Qiita
posted articles:オブジェクト指向:43%oop:43%CleanArchitecture:43%PHP:29%C#:29%
書籍「マイクロサービスアーキテクチャ」まとめ（後編） - Qiita
前編 につづいて、書籍 マイクロサービスアーキテクチャ のまとめです。 要点 ８章．監視 システムを複数のサービスに分割することで、個々のサービスの状態やサービス間のネットワークなど、監視すべき項目が増える。手動による監視では間に合わなくなるので、情報を自動的に収集し、運用監視に適したビューを提供する必要がある。 マイクロサービスでは、サービスのスケールによって監視対象のサーバなどが動的に増減する。監視の仕組みではそのような動的な監視対象の変化に自動的に追随できる必要がある。 監視はシステム全体で統合的に行う必要があるので、個々のサービスの独自ルールにするのではなく、システム全体でルールやツール、ライブラリなどを統一しておく。 ログやメトリックなどの収集した情報には、サービス開発者が必要なときにすぐにアクセスできるようにしておく。(誰かに依頼しないと入手できない、では遅い) マイクロサービ
書籍「マイクロサービスアーキテクチャ」まとめ（前編） - Qiita
はじめに O`REILLY発行の マイクロサービスアーキテクチャ を読みました。 非常に興味深く、これまで主に企業向けエンタープライズ開発に関わってきた自分にとっては、今後のソフトウェアエンジニアとしてのキャリアを作っていくには、考え方の転換が必要だと気付かされる内容でした。 本書の内容は広範囲に渡りますが、特に重要と感じた要点を整理(かなり長いですが)しておきたいと思います。（後編 との2部構成です） 要点 はじめに マイクロサービスを取り巻く技術の進歩は早く、マイクロサービスを実現する特定の技術を習得することよりも、その本質的な考え方を理解することが重要である。 １章．マイクロサービス マイクロサービスとは マイクロサービスはSOA(サービス指向アーキテクチャ)のひとつの実現形態であり、DDD(ドメイン駆動設計)、CI・CD(継続的インテーグレーション・デリバリ)、インフラ仮想化、自動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
