タグ

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

  • 宣言的UIはReact Hooksで完成に至り、現代的設計論が必須の時代になる - Qiita

    この記事は、ある程度以上の規模のGUI開発において、React Hooks以後の宣言的UIにより、大規模開発に用いられる設計論に完全に対応できるようになり「ビジネスロジックの変更や追加」に対応するコストを低く保つこと(技術的負債の抑制)ができるようになったことを解説するものです。 技術的負債の抑制には、技術的負債の原因となりがちな「広範囲の密結合」と「適切な疎結合を保つ仕組みの欠如」が欠かせません。それをカバーするのが、大規模開発をクリーンに行える設計論(ここでは「現代的な設計論」とよぶもの)です。クリーンアーキテクチャなんかでGUIによく適用されるHumble Object Patternのようにプレゼンテーションとビューを分離する必然性が無くなるでしょう。 ポイントは ある程度以上の規模で開発するなら設計論をうまく使い設計しないと、技術的負債を抱え込む(ビジネスロジックの変更や追加に対

    宣言的UIはReact Hooksで完成に至り、現代的設計論が必須の時代になる - Qiita
  • AWS CDKでWeb3層アーキテクチャを作成してみた | DevelopersIO

    はじめに おはようございます、加藤です。これまで、エンジニアとしてのキャリアは全てインフラエンジニアでしたが、今月からプログラマーとしてのロールを希望してゼロから再スタートしております。 今回、AWS CDK(以降、CDK)を使って典型的なWeb3層アーキテクチャを構築してみたので、こだわったポイントや使う過程で理解した事をご紹介します。 リポジトリはこちらです。 kmd2kmd/aws-cdk-ec2_web3tier ある程度CDKを理解されている方を前提として書いております。下記のブログを読む、Workshopを試した経験がある程度の理解が必要です。 AWS CDK が GA! さっそく TypeScript でサーバーレスアプリケーションを構築するぜ【 Cloud Development Kit 】 | DevelopersIO TypeScript Workshop :: AWS

    AWS CDKでWeb3層アーキテクチャを作成してみた | DevelopersIO
  • ソフトウェアアーキテクチャの歴史 - tasuwo's notes

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

    ソフトウェアアーキテクチャの歴史 - tasuwo's notes
  • Aurora - クラウド時代のDBアーキテクチャ - 発明のための再発明

    はじめに Amazon Auroraは、AWSを触る人ならほとんどの人が利用を検討したことがあるでしょう。 Amazon社内ではOracleを止めたというtweetもありました SHUTDOWN ABORT the last Oracle database running Amazon Fulfillment! pic.twitter.com/DorqTua2Lt— John Darrow (@jdarrow) 2019年3月29日 そんなAuroraは、従来のRDBとは違いクラウド上で動くことを念頭に設計されています。 また、ログが中心的な役割を持つことから「The log is the database」と表現されることもあります。 そんなAuroraの仕組みについての論文を読んだので紹介します。 読んだ論文は以下の2つです。 Amazon Aurora: Design Conside

    Aurora - クラウド時代のDBアーキテクチャ - 発明のための再発明
  • Laravelで実践クリーンアーキテクチャ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Archit

    Laravelで実践クリーンアーキテクチャ - Qiita
  • なぜアーキテクチャ図を必要とするのか?

    正しいドキュメントの適切なバランスを見つけるために、次のエクササイズをチームで試してみよう。まず各同僚に、技術ドキュメントに当に必要なもの、そこに含めるべき図の種類について質問する。彼らの意見を集約して、ブレインストーミングを実施し、チームにとって当に必要なものについて合意をとる。チームの外部に、追加の要求を持つ影響力のあるステークホルダーが1、2名いるかもしれない。彼らのニーズを考慮することもまた、アーキテクトの責務だ。以上に基づいて、ステークホルダーのニーズを満たす適切な量とレベルの技術ドキュメントを作成する。もし開発者がドキュメントの真の価値を理解し、その価値を保つことに関心を持てるなら、進んでドキュメントに貢献し、適切に保守してくれるだろう。最終的に、全員がハッピーになる。しかし、もしその必要性を理解しなかったり、気にしないのなら、それについてはほとんど忘れてしまって構わない。

    なぜアーキテクチャ図を必要とするのか?
  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ!」という答えはない。 プログラミング言語や、フレー

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
  • 巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明

    はじめに この記事は設計・アーキテクチャ Advent Calendar 2018の1日目の記事です。 大きなサービスを支えるのは一筋縄では行かず、考えることは多くあります。しかし、ありがたいことに巨大な企業の中にも自社のサーバー構成やそれを支えるツールを公開している企業があります。 この記事では、彼らの叡智に触れるため、有名企業の事例を取り上げ要約をします。 各事例には元記事へのリンクを書いているので、興味があればリンク先も覗いてみてください。 ※新しいものばかりではないので、古くなっていたり既に別の方法に移行している可能性があることに注意してください。 LINE: 25k/secのスパイクをさばくアーキテクチャ 元記事: 25K request/secをさばいた「LINEのお年玉」のアーキテクチャの裏側 最初に紹介するのは、LINEが2018年に実施した、「LINEのお年玉」というイベ

    巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明
  • なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明

    なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
  • 思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall

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

    思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
  • 大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD

    バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高

    大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD
  • クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita

    はじめに クリーンアーキテクチャの書籍を読んだので、実際にクリーンアーキテクチャの考え方を採用したREST APIGO言語で実装してみた。 ↓↓↓↓ソースコード↓↓↓↓ https://github.com/yoshinorihisakawa/sample-api-hoop/tree/develop この記事ではクリーンアーキテクチャの説明というよりかは、実装ベースの実践的な内容にしている。 対象読者 ・クリーンアーキテクチャで実装されたソースコードを理解したい人 ・クリーンアーキテクチャの右下の図がよくわからない人 ・アーキテクチャについて勉強を始めた初心者 クリーンアーキテクチャとは? クリーンアーキテクチャとは、8th Light, Inc.のブログ記事で提案されている。 一言で言うと、依存関係をコントロールし持続可能なソフトウェアを実現するための体系的な手法である。 ※ DIやD

    クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita
  • 書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみた - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ。 なぜソースコードを綺麗に書くのかから始まり、オブジェクト指向、コンポーネントの原則、アーキテクチャと体系的にまとまっている良い内容だった。 この記事では、書の内容の引用を踏まえながら自分の考えの振り返りをまとめたものである。 実際にGoで実装したりしたので、なにか間違いなどあれば指摘していただきたい。 クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた 対象読者 ・Clean Architecture 達人に学ぶソフトウェアの

    書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみた - Qiita
  • サービスメッシュについて調査してみた件 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 最近、Kubernetesを中心としたコンテナ環境やマイクロサービスの文脈において、「サービスメッシュ」「Istio」というキーワードを聞く機会が増えています。 「Istio」は、2018/7/31にバージョン1.0に到達したことが発表され、ますます注目されるオープンソースソフトウェアとなっています。また、自分が所属しているSIerであっても、最近「サービスメッシュ」という言葉を聞く機会が増えてきています。 記事では、サービスメッシュの概要から、サービスメッシュを実現するソフトウェアについて、Web上の情報などを元に調査した

    サービスメッシュについて調査してみた件 - Qiita
  • AWSを学ぶために最初に構築するアーキテクチャパターン5選 - log4ketancho

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

    AWSを学ぶために最初に構築するアーキテクチャパターン5選 - log4ketancho
  • SQLServer 2014 “Hekaton”再考 - 急がば回れ、選ぶなら近道

    SQLServer2014「Hekaton」 MSの主要DB。論文がでているので、それをベースに自分の理解を書く。当然実装は公開されていないので、合ってるかどうかは知らない。また実際に製品にテストベンチを走らせたわけではないので、あくまで公表された論文ベースでの理解になる。まぁもう普通に使われているDBで、細かい機能云々についてはいろいろ資料がでているはず。そのあたりを見ればいいと思う。論文が公表されて、だいぶいろいろ手がはいっているとは思うので「アーキテクチャの設計」として読んでる。 ■論文の構成 基的に三つの構成になっている。全体の枠組み・Txの処理を詳細に記述したもの・およびその厳密な証明。このうち、全体の枠組みは、Tx処理詳細のあとで書かれているので、若干の不整合がある。これはIndex実装の追加の話なので、多分パフォーマンス向上のためにRange Indexを追加したようだ。ト

    SQLServer 2014 “Hekaton”再考 - 急がば回れ、選ぶなら近道
  • レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺 - まっつんの日記

    自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの来の考えはOOUIや、コプリエンのLean Architectureが良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。(自分はこれをや

    レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺 - まっつんの日記
  • 知っているようで知らないWebサーバアーキテクチャ

    第6回ゲームサーバ勉強会用資料です。 Webの技術の根幹となるHTTPやTCP/IPを軽くおさらいしたあと、 マルチプロセス、マルチスレッド、イベント駆動といったサーバアーキテクチャについて解析し、 さらにイベント駆動を実現するための非ブロッキングI/OとI/Oの多重化について解説します。

    知っているようで知らないWebサーバアーキテクチャ
  • 10分で振り返るソフトウェアアーキテクチャの歴史2017

    CAMPFIRE iOS #1 - connpass https://yj-meetup.connpass.com/event/51735/ での発表資料です。 (2017/3/23追記): 各所からいただいたフィードバックに基づき、不正確な記述を修正しました。(Nyohoさん、あんざ…

    10分で振り返るソフトウェアアーキテクチャの歴史2017
  • マイクロサービスアーキテクチャに最適化したJavaを実現するための「MicroProfile」、Eclipseの正式プロジェクトに

    マイクロサービスアーキテクチャに最適化したJavaを実現するための「MicroProfile」、Eclipseの正式プロジェクトJavaで業務アプリケーションを構築する場合には、一般にフレームワークとしてJava EEが採用されることが多いでしょう。しかしJava EEは業務アプリケーションに求められる機能を幅広く網羅した大きなフレームワークであることから、より軽量なJavaフレームワークへのニーズも根強くあり、実際に軽量な業務アプリケーション向けJavaフレームワークもこれまでにいくつも登場してきました。 また、Java EE自体もそうした軽量なフレームワークへのニーズに応えるため、特定の機能を抜き出してまとめる「Profile」という概念を採用するようになりました。例えばWebアプリケーションに最適化した「Java EE Web Profile」などはその一例です。 Microse

    マイクロサービスアーキテクチャに最適化したJavaを実現するための「MicroProfile」、Eclipseの正式プロジェクトに