『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 での発表資料です https://timeedev.connpass.com/event/254336/ 動画: https://youtu.be/ydQ2xoc49Lc #Techmee
こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます
Arm入門勉強会とは、macOSがArmに移行したこの機にArmアーキテクチャでのプログラミングについて入門するソフトウェアエンジニアのための会です。OS開発に必要なArmの低レイヤーなプログラミングについて、金津穂氏が共有しました。前半はArmの実行モデルと割り込みについて。全2回。 概要と自己紹介 金津穂氏(以下、金津):「AArch64とOS入門」ということで金津が発表いたします。 はじめにですが、「これからArmでOSを自作したい!」という人向けのまとめ資料になります。なので、すでにArmでお仕事している人、とくに組み込み向けだったりとかすでにOS開発とかしている人にとってはもう既知の情報しかない。あと、リファレンスマニュアルを自分で読める人にとっては、それを読んだほうが確実な情報が手に入るんじゃないかなと思います。 Armと題してますけど、基本的にはAArch64だけにします。A
本書は、Micro Frontends Architecture Patternsというタイトルを付けていますが、モノリスからJAMstack、Micro Frontendsまで、Webフロントエンドを包括した様々なアーキテクチャパターンの詳細を体系的に紹介しています。 ソフトウェアとしてのアーキテクチャ全体を俯瞰し、他のシステムとのやりとりを設計するような考え方が役に立つことは多いです。フロントエンド観点で、様々なアーキテクチャパターンをまとめることで、Web開発の助けになればと考えています。 また、アーキテクチャの歴史と変遷を知ることで「Micro Frontends」への理解を深めることができると筆者は考えました。Micro FrontendsはThoughtWorksのTechnology RadarではすでにADOPTとなり、海外で多くの事例が存在します。Micro Fronte
これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、(レポートというよりも)考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話(触ってみたレベルでなく実運用等を経たもの)についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
2018年10月に公開した「ミクシィの技術スタックについてまとめてみた」。こちらの記事ですが、SNSやブログ等で反響をいただきました。他の企業さんも、ここ数年で自社の技術スタックの公開する傾向が進んだかと思います。 ……「で、第二弾はないの?」という声をチラホラいただきましたので要望にお応えする形で、第二弾を公開。ミクシィを代表するサービス群はもちろん、updateされたサービス、新規開発中のサービスまで、各サービス/事業部で、開発言語・インフラ環境・デプロイツールなどでまとめてドドーンと公開します。 ※サービスやプロダクトに該当しないケースは、各事業部で採用している技術を紹介します ※2020年9月30日時点での情報です ※記事ボリュームがありますので、可読性を考慮し2ページに分割しております 【サービスおよび、技術スタック一覧】 目次 モンスターストライク TIPSTAR コトダマン
電子情報学特論: Chromium のアーキテクチャを解き明かす 〜 EEIC の授業が生きるプロダクトの世界〜 Kentaro Hara 2020 April (๑>ᴗ<๑) * * * *
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの?」 という
はじめに 昨年からの大きな案件でClean Architectureを使った Platforms: Android/iOS Languages: Kotlin/Swift はじめに 勉強会向け資料なので、クリーンアーキテクチャー自体の解説もある程度含まれます。 逆に、時間の都合上、歴史背景や細かい部分までは行き届いていません。 もし間違いがあればご指摘ください。 オススメ書籍 アーキテクチャーを選定する目的 求められるシステムを構築・保守するために必要な人材を最小限に抑えるため 「アーキテクチャーは上位レベル、設計は下位レベル」のように区別されることがあるが、両者の間に明確な境界はなく、上位から下位に至るまで、決定の連続である スマホアプリ開発で代表的なアーキテクチャー AndroidはMVVM(Googleが推奨) iOSはMVC(AppleがCocoa applicationに採用)
※1:Interactorは利用シーン(ユースケース)に応じてクラス分割するため、画面と1:1ではない ※2:Entityはテストの際に差し替える必要がないほどシンプルな構造なのでプロトコル不要 ※3:1つのモジュールで複数のEntityを扱うこともあるため それぞれの役割の詳細 以下ではサンプルコードを元に説明 GitHubのAPIをたたいてリポジトリの一覧を取得し表示する Router 「画面遷移」と「DI」を担当 VIPERアーキテクチャの肝であり、他の有名アーキテクチャにないところ 他アーキテクチャではViewに画面遷移の処理もお願いする必要があり、Viewが「画面の更新」と「画面遷移」の2つを担当する必要があった →Viewのコードの見通しが悪くなりがちだった VIPERでは「画面遷移」の処理を Router に移管したことで View の責務を減らせ、可読性の向上が望める Ro
何番煎じだよって感じですが、アーキテクチャに対する考え方は割と正解がなくて、自分の中に一つ落とし込んでおいて損はないと感じたため、備忘録という形で記事にさせていただきます。 アーキテクチャとは?一言でいうと、 アプリケーションを綺麗に実装するための設計方法! アーキテクチャを考慮しない設計でコードを書いていると以下のような課題にぶち当たります。 一つのクラスの肥大化(iOSで言うところのFatViewController)ロジックが煩雑になる同じ処理を使い回せないチーム開発で役割分担しにくいテストがしにくい属人化が進み、引き継ぎが難しくなる機能の追加,修正が困難etc…正直まだまだあるとは思いますが、とにかく設計はこだわってないと後で地獄を見るということさえ伝わればOKです。 Sample Appアーキテクチャを語る上で叩き台にするアプリがいるなーと思ったので作りました。 閲覧するときは、
本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か?押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か?何が正しくて何が間違っているか?も重要なのだが、それよりは、なぜそれが生まれたのか?何を解決しようとしたのか?どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか?を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
はじめに 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
最近では「マイクロサービス」と呼ばれる、機能毎に細かくサービスを分割して開発や運用を行うアーキテクチャの採用例が増えている。本記事ではこのマイクロサービスアーキテクチャや、それに使われる技術について紹介する。 マイクロサービスとは 近年、ITシステムの開発・運用において「Microservice(マイクロサービス)」というアーキテクチャを採用する例が増えている。マイクロサービスアーキテクチャは、簡単に言えばサービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法で、2011年ごろから提唱されているものだ。 マイクロサービスについては、2014年に公開された「Microservices」という文書が有名だ(有志による日本語訳)。また、さくらのナレッジでも2015年に紹介されている。マイクロサービスの詳しい思想についてはこれら記事を参照してほ
アプリについて リリースしたアプリはこちらです。 https://play.google.com/store/apps/details?id=com.teach_timetable_appppppp.www.teachtimetable ソースコードはこちら https://github.com/fungiy/TeachTimeTable 学校の先生向けの時間割アプリ。 言語はKotlinです。 作ってる途中に考えたことなんかをコードを交えながら解説してみます。 間違った記述があればご指摘ください。 また、ここはこうしたほうがいいみたいなご指摘も大歓迎です。 (プルリクもお待ちしてます) クリーンアーキテクチャは以下の図が有名だと思います。 クリーンアーキテクチャでは、ビジネスロジック(ドメイン層)を中心に置き、データベース・ネットワークアクセスなどのインフラ層と、UI層を外側として扱いま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く