タグ

アーキテクチャに関するbraitomのブックマーク (38)

  • デザインパターン - Google Cloud のソリューション

    ウェブサイト リニューアルおよび移行のお知らせ 2022 年 7 月 Google Cloud Solution Design Pattern のウェブサイトはリニューアルを行い、以下に移行いたしました。より使いやすくなっておりますので、これまで以上にご活用いただけますと幸いです。 gc-solution-design-pattern.jp ソリューション デザインパターン とは ソリューション デザインパターンでは、 ワークロードごとに Google Cloud のアーキテクチャを 2 つの観点でまとめています。 1 つ目は、様々な業界で利用できる共通のソリューション デザインパターンとして「エンタープライズ向けの組織、 IAM、請求管理」、「インフラストラクチャとマイグレーション」、「アプリケーションおよびデータベースのモダナイゼーション」などを用意しています。 2 つ目は、ゲーム業界

    デザインパターン - Google Cloud のソリューション
    braitom
    braitom 2020/12/25
    GCPのソリューションデザインパターンまとめページ。システムのデザインパターンだけでなく企業で使うときの管理方法もまとめられている。
  • Shopifyはいかにしてモジュラモノリスへ移行したか

    原文(投稿日:2019/07/29)へのリンク ShopifyのシニアエンジニアであるKirsten Westeinde氏がShopify Unite 2019で、Shopifyにおけるモジュラモノリス(modular monolith)への展開について論じた。変更をいつ行うか、どのように達成するか、といった判断にデザインペイオフラインを使用したこと、ターゲットアーキテクチャからマイクロサービスを除外した理由、などがその内容だ。 重要な点は、モノリスは必ずしも悪いアーキテクチャではなく、単一のテストおよび展開パイプラインなど多くのメリットがある、ということだ。新たな機能を短期間で提供する必要のあるプロジェクトを立ち上げるには、これは非常に有用だ。アーキテクチャの改善に着手すべきなのは、"設計のペイオフライン"を越えた時、すなわち設計の悪さが機能開発を妨げるポイントにおいてのみである。Sho

    Shopifyはいかにしてモジュラモノリスへ移行したか
    braitom
    braitom 2019/10/31
    Shopifyのアーキテクチャ設計について。マイクロサービスではなくモジュラモノリスパターンを採用した理由、どのようにマイグレートしたかが書かれている。
  • ソフトウェアアーキテクチャの歴史 - tasuwo's notes

    改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。来の MVC とは何か?何が正しくて何が間違っているか?も重要なのだが、それよりは、なぜそれが生まれたのか?何を解決しようとしたのか?どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか?を知りたい。しかし、そういうことがまとまっている日語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M

    ソフトウェアアーキテクチャの歴史 - tasuwo's notes
    braitom
    braitom 2019/06/29
    ソフトウエアアーキテクチャの歴史について。Classic MVC、MVP、MVVMなどの概要や関連性などが網羅的にまとめられている。
  • アーキテクチャのレビューについて - JaSST Review '18

    2018年12月14日に行われたJaSST Review'18(ソフトウェアレビューシンポジウム 2018)での講演「アーキテクチャのレビューについて」の資料です

    アーキテクチャのレビューについて - JaSST Review '18
  • ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ

    概要 ドメイン駆動設計の有名な用語にエンティティというものがあります。 ほとんどドメイン駆動設計の代名詞のひとつと言っても過言でないほどの有名さを誇るこちらの用語ですが、なんとクリーンアーキテクチャにもまったく同じエンティティという用語が出てきます。 このエンティティという用語は名前こそ同じではありますが、実は完全に同じものを指しているわけではありません。 とはいえまったく違うものである、というわけでもありません。 要するにややこしい。 この記事はこのややこしい用語について、ドメイン駆動設計とクリーンアーキテクチャのそれぞれのエンティティが何を指していて、それがどのように異なっているのかについてを解説します。 それぞれのエンティティ そもそもエンティティとは何でしょうか。 英和辞典を引くとエンティティとは「存在[実在]物」といった意味が出てきます。 これはかなり抽象的な意味です。 つまり、

    ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ
  • なぜアーキテクチャ図を必要とするのか?

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    なぜアーキテクチャ図を必要とするのか?
    braitom
    braitom 2019/02/28
    アーキテクチャ図について。誰のために書いているのか、何のために必要なのかなどが書かれている。
  • オーバーエンジニアリングと技術的負債を見極める––SmartHRが明かす、成長の軌跡と技術選定 - Part2

    SmartHRのインフラの変遷 内藤研介氏:開発言語とコミュニティへの貢献に続きまして、ここからはインフラとか開発環境について、お金技術的選択を軸にお話ししたいと思っております。 一般的に、私たちのようなB to Bサービスは、B to Cサービスに比べるとユーザー数は少ない傾向にあります。その中でもSmartHRは、主に社内の管理者が使うサービスなので、サービス自体の特性としてインフラの投資がめちゃくちゃ必要なものでもないです。 こちらの数字は、2015年11月に番リリースした際のサーバ費用です。ステージング環境も含めた費用ですね。非常に経済的なアーキテクチャだったわけです。料金のうちのほとんどはAWSの、RDSというデータベースのサービスです。あとはElastiCacheというキャッシュのサービスとか、そういった部分が占めていました。 詳しい方が聞かれるとちょっと驚かれるかと思うん

    オーバーエンジニアリングと技術的負債を見極める––SmartHRが明かす、成長の軌跡と技術選定 - Part2
    braitom
    braitom 2019/02/13
    これ大事だよなあ“私たちエンジニアは常にオーバーエンジニアリングと、こういった将来にわたる技術的負債、そういったバランスを取りながら技術的選択をしていく必要があると考えております”
  • なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

    このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで

    なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
  • クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜 - クックパッド開発者ブログ

    インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い

    クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜 - クックパッド開発者ブログ
    braitom
    braitom 2018/12/30
    クックパッドの大規模アーキテクチャ刷新プロジェクトの概要や戦略について。すごいな。
  • 思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall

    2. What is Software Architecture ● IEEE1471「コンポーネント、それらの関係や環境、設計やそのコンポーネント、それらの関係や環境、設計やそのそれらの関係や環境、設計やその関係や環境、設計やそのや環境、設計やその環境、それらの関係や環境、設計やその設計やそのや環境、設計やそのその関係や環境、設計やその 進化を左右する原則に具現化されたシステムの基的な構成」を左右する原則に具現化されたシステムの基的な構成」左右する原則に具現化されたシステムの基的な構成」する原則に具現化されたシステムの基的な構成」原則に具現化されたシステムの基的な構成」に具現化されたシステムの基的な構成」具現化を左右する原則に具現化されたシステムの基的な構成」されたシステムの基的な構成」システムの基的な構成」の関係や環境、設計やその基的な構成」な構成」構成」」 ● M

    思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
    braitom
    braitom 2018/12/17
    品質特性間のトレードオフ、代表的なアーキテクチャパターンとそのトレードオフ、アーキテクチャ設計の評価の仕方、記録とメンテの仕方などについてまとめられている。
  • AWSを学ぶために最初に構築するアーキテクチャパターン5選 - log4ketancho

    先日書いた AWS の勉強方法をまとめた記事(AWSを学ぶ上でやってよかった勉強法5選 - log4ketancho)で、「簡単なWebサービスAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「2)簡単なWebサービスAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります!業務で使う分にはサーバー何台立てようが気になりませんが(は言い過ぎですがw)、個人でサービスを運営する場合はそうはい

    AWSを学ぶために最初に構築するアーキテクチャパターン5選 - log4ketancho
  • BFF/SSRの話

    Mercari Web / Frontend meetupで話した BFF/SSR の話です。

    BFF/SSRの話
    braitom
    braitom 2018/02/20
    Backend For Frontendとは何か、なぜ必要なのか、歴史、SSRとの関係についてまとめられている。
  • すべての開発者が知っておくべき、ソフトウェアアーキテクチャに関する5つのこと

    Mark Fussell氏とYaron Schneider氏とDaprを知ろう 日のエピソードでは、Thomas Betts氏がMark Fussell氏とYaron Schneider氏に、分散アプリケーション・ランタイム(Dapr)について話を聞いた。最新のInfoQ Architecture and Design Trends Reportでは、Daprはポータビリティとクラウドアプリケーションのための設計というアーリーアダプターのアイデアの一部となっている。

    すべての開発者が知っておくべき、ソフトウェアアーキテクチャに関する5つのこと
    braitom
    braitom 2018/01/29
    ふむ。“多くのモダンなソフトウェアアーキテクトは、コーディング、コーチング、コラボレーティブな設計を活かしたアプローチを好む”
  • クックパッドでの Webアプリケーション開発 2017 / Web application development in Cookpad 2017

    Rails Developers Meetup #7 東京会場 https://techplay.jp/event/631428

    クックパッドでの Webアプリケーション開発 2017 / Web application development in Cookpad 2017
    braitom
    braitom 2017/11/18
    hako-console、pull-request staging。すごい。
  • サーバーレスについて語るときに僕の語ること // Speaker Deck

    サーバーレスについて最近思っていることをポエムしました. サーバーレス過激派です. Presented at Serverlessconf Tokyo 2017.

    サーバーレスについて語るときに僕の語ること // Speaker Deck
    braitom
    braitom 2017/11/05
    Event DrivenなシステムとFaaSについて
  • クックパッドのログをいい感じにしているアーキテクチャ / Logging architecture at Cookpad

    Cookpad Tech Kitchen #9 https://cookpad.connpass.com/event/60831/

    クックパッドのログをいい感じにしているアーキテクチャ / Logging architecture at Cookpad
    braitom
    braitom 2017/07/27
    なぜログを集めるのか、ログの要件、クックパッドが利用しているサービスとその構成についてまとめられている。
  • 10分で振り返るソフトウェアアーキテクチャの歴史2017

    CAMPFIRE iOS #1 - connpass https://yj-meetup.connpass.com/event/51735/ での発表資料です。 (2017/3/23追記): 各所からいただいたフィードバックに基づき、不正確な記述を修正しました。(Nyohoさん、あんざいゆきさん、かとじゅんさん、ありがとうございます) また、参考リンク集を追加しました。 ## 参考リンク ■ MVC Pattern http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf ■ Understanding JavaServer Pages Model 2 architecture | JavaWorld http://www.javaworld.com/article/2076557/java-web-develop

    10分で振り返るソフトウェアアーキテクチャの歴史2017
  • 技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記

    ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ? 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから? o 信用できないテストデータ も負債 o 現

    技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
  • 何故TimersのiOSチームではモダンアーキテクチャを採用しないのか - Tech Blog

    明けましておめでとうございます!年もよろしくお願いします! 年末からを飼い始めてなるべく早く家に帰りたいかっくん(@fromkk)です。 最近iOS界隈ではMVC以外のアーキテクチャが流行ってますね。 ベースは昔からあるMVCですが、MVPやMVVM、VIPER、Clean Architecture等など... どれもメリット/デメリットあるかと思いますが、弊社のiOSチームではどれも採用せずに昔からのMVCでプロジェクトを進めています。 何故他のアーキテクチャを採用しないのか 一言で言うと学習コストが高いのが大きいです。が、それだけでも無いので細かく記述したいと思います。 学習コスト 先述しましたが今と違うことをしようとするとどうしても学習コストが高くなります。 また、一人ならいいですが複数人いる場合はチーム内の皆も同じく学習する必要があります。 個々人のスキルに差が合ったり、メンバ

    何故TimersのiOSチームではモダンアーキテクチャを採用しないのか - Tech Blog
    braitom
    braitom 2017/01/21
    iOSアプリ開発時にMVVM、VIPER等のアーキテクチャを採用しないで元々のMVCを採用している理由について。学習コストが高くなる、RxSwiftなどの外部ライブラリに依存してしまうなどの理由を挙げている
  • FastContainerアーキテクチャ構想 - 人間とウェブの未来

    追記:この記事へのコメントとして、この記事以上に内容の趣旨を端的かつ完璧に表しているコメントがありましたので、まずはそれを紹介しつつ、引き続き呼んで頂けると幸いです。 FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる by takahashim FastContainerアーキテクチャ構想 - 人間とウェブの未来 FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる2016/11/13 18:25 b.hatena.ne.jp 素晴らしいまとめの一言です。それがまさに構想に至った意図でございます。僕もこんな趣旨をかけるようになりたいです。上記の的確なコメン

    FastContainerアーキテクチャ構想 - 人間とウェブの未来
    braitom
    braitom 2016/11/12
    FastCGIの考えかたをWebアプリを提供するコンテナがたくさんあるシステムに適用する構成。FastContainerアーキテクチャ。