SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
クリーンアーキテクチャの功罪
クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。 最近目にしたクリーンアーキテクチャに対する批判 本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。 ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。 書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により
ぼくのかんがえたさいきょうの個人開発あーきてくちゃ
前置き この記事で紹介するアーキテクチャはあくまで机上論であり、筆者が実際にこれらのアーキテクチャでサービスを運用したことがあるわけではありません。 そのため、考慮漏れ等あるかもしれません。その際はご指摘いただけますと幸いです。 モチベーション 個人開発でアプリケーションを作って運用したい！ お金は極力かけたくない！ けどいい感じのツールを組み合わせてクールなアーキテクチャにしたい！ 対象とするアプリケーションの概要 ブラウザで動くウェブアプリケーション 認証機能を持つ DBはNoSQLではなくRDB アプリケーション本体とは別に管理画面アプリケーションが必要 以上を前提として考えました。 ぼくのかんがえたさいきょうあーきてくちゃ こちらです。 コンポーネントごとに解説させてください。 フロントサーバー Next.js on Vercelです。 こちらはもはや説明不要の王道構成かと思います
Rust で DDD を実践しながら API サーバーを実装・構築した（つもり） - Qiita
Rust 勉強中の身ですので、何かしら作ってみようと思い立ち、 API サーバーを構築してみました。 自力で一から公開できるサーバーを構築したのは初めてでしたので、試行錯誤の過程を記事にします。 作ったもの 何の変哲もない API サーバーです。 成果物は こちら にアップしました。 API サーバー Rust で実装 Web フレームワーク（Actor）: actix-web ORM: Diesel Docker イメージにして Heroku で稼働させる DB サーバー PostgreSQL を利用する Heroku PostgreSQL で稼働させる 開発方針 上記のインフラ構成を目標として、以下の開発方針を軸として調査や検証を行いました。 ローカルでの開発とサーバーへのデプロイはスムーズにできるようにする。 ローカルでテストや動作確認がスムーズにできるようにする：Docker の利
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webパフォーマンス高速化とこれからのアーキテクチャ
先行開発！Javaでクリーンアーキテクチャ / Clean architecture with java