アーキテクチャと設計は全然違う⋯ただしあなたの想像する”違い”とは多分全然違う【輪読会発表紹介】 - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。エンジニアリンググループ内では技術書の輪読会が有志によりいくつか立ち上がっています*1。そうした勉強会の一つで発表した内容が社内で少々バズったので、これは社内だけじゃもったいないとご紹介させていただきます。 本は、「ソフトウェアアーキテクチャの基礎（オライリー・ジャパン、Mark Richards/Neal Ford著 島田浩二訳）」。その第2章です。 謝辞をまず この章は 知識の”幅”と”深さ”だ 幅広さ→候補とメリデメ→ビジネス動機に即した判断 深さ→最新アップデートに追いつき続けること→偏らない判断 まとめ 参加者の感想など We are hiring! ソフトウェア アーキテクチャ基礎 輪読会資料 第2章 アーキテクチャ思考 from 琢磨 三浦 謝辞をまず この本の輪読会を立ち上げてく
doda アプリ開発グループの坂戸です。 今回は doda アプリがどのような技術を使用してアーキテクチャ・設計しているかをお話しします。 前半部分をフロントエンド、後半部分をバックエンドに分けて説明していきます。 フロントエンド doda アプリのフロントエンドはざっくり以下の構成で成り立っています。 ReactNative ReactNativeFirebase typescript ReduxToolkit Realm jest 今回は設計のお話をしたいので、各ライブラリの詳細な説明などは割愛させていただきます。 まずは外観をご覧ください。 dodaアプリフロント概要 Redux フロントエンドで取り扱うデータを格納する層です。 各ドメインの粒度でSliceを切ってデータを管理しております。 ディレクトリ構成は Re-ducks パターンを採用。基本的にはReduxの原則に則って管理
はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて
新規プロダクトでKubernetesを中心にCloudNativeなアーキテクチャのインフラを導入した話 | Tech Blog
新規プロダクトでKubernetesを中心にCloudNativeなアーキテクチャのインフラを導入した話 Tech Blog 2019.08.26 はじめに アドテク本部Airtrackチームの横山（@nnao45）です。 チーム内ではScala書いたり〜K8Sと遊んだり〜AWSったり〜しています。 この度Airtrackチームの新規プロダクトでKubernetesを採用し、本番環境に投入したのでその知見を共有させた頂きます。 おしながき 目指したアーキテクチャ Kubernetes周り ミドルウェア CI/CD 監視 感想 目指したアーキテクチャ 妥協はしないが身の丈にあったコンテナプラットフォーム って感じですかね。 Kubernetes周り サービスレイヤひとまわり Airtrackチームで広告系完全新規プロジェクトの立ち上げに Kubernetes中心にクラウドネイティブなアーキテ
「作って学ぶコンピュータアーキテクチャ」の環境を再現するためのDockerイメージをリリースします - FPGA開発日記
「作って学ぶコンピュータアーキテクチャ」(いわゆるRISC-V + LLVM本)は書籍執筆時の状況と出版時のツールチェインの状況がかなり変わってしまっており、各所で迷惑をかけてしまっています。 確実にLLVMビルド + シミュレーションを行うために、ツールチェインを含んだDockerイメージをリリースします。 github.com 大きく分けて4つのイメージを用意しています。 ubuntu_2204 Ubuntu 22.04の環境を使用し、新しいRISC-Vツールを使用したDocker環境です 本書で説明している実行コマンド列と大きく異なっている場所があります LLVMリポジトリはコンテナ内にダウンロード済みです(コンテナ容量削減のためビルドは行っていません) 最終的なバイナリのみ必要な方向けです ubuntu_2204_onlyenv Ubuntu 22.04の環境を使用し、新しいRIS
宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践/swiftui-graphql
宣言的UI https://speakerdeck.com/sonatard/xuan-yan-de-ui GraphQL実践ノウハウ https://speakerdeck.com/sonatard/graphql-knowhow GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql #RoppongiGraphQL https://twitter.com/sonatard/status/1439124499023101952
アーキテクチャ大全 - kawasima
お気に入り / ページネーション / 検討リスト / カテゴリ毎の件数表示 / Conversation threading / オートログイン / 途中保存 / 予約 / 未読管理 / アンケート
Apple A4チップやAMD Ryzenの生みの親であるジム・ケラー氏がNVIDIAのCUDAとx86アーキテクチャを「沼」と呼んで批判
AMDのAthlonやZenマイクロアーキテクチャ、Apple A4などさまざまなチップの開発に携わったアーキテクトでエンジニアのジム・ケラー氏が、X(旧Twitter)で「NVIDIAのCUDAは沼です」と批判したことが報じられています。 Jim Keller criticizes Nvidia's CUDA, x86 — 'Cuda’s a swamp, not a moat. x86 was a swamp too' | Tom's Hardware https://www.tomshardware.com/tech-industry/artificial-intelligence/jim-keller-criticizes-nvidias-cuda-and-x86-cudas-a-swamp-not-a-moat-x86-was-a-swamp-too ケラー氏の経歴は以下の記事を
理想的なマイクロサービスアーキテクチャを目指す継続的改善 / Re-architecturing of Microservices #CNDT2019
CloudNative Days Tokyo 2019 で発表した資料です。 理想的なアーキテクチャを目指してマイクロサービスアーキテクチャを継続的に改善する「Re-architecturing」という取り組みについて話しました。 cf. https://cloudnativedays.jp/cndt2019/
AWS CDK+Serverlessのアーキテクチャパターンの実装が勢揃い！CDK Patternsの紹介 | DevelopersIO
はじめに CX事業本部の佐藤智樹です。 今回はAWS CDKでServerlessアーキテクチャを構築する上で参考となる実装が紹介されているCDK Patternsという取り組みが気になったので紹介します。 実装はGitHub上で公開されているので、いつでもすぐにcloneして動かすことができます。 この記事を読むことでAWS CDK+Serverlessで何か開発する際の設計パターンが分かり、独自に検討するより早く実装できるようになります。 正直自分でもこのパターンいいじゃん！使いたい！となったので、CDKで何か作ってる方には絶対参考になると思います。 CDK Patternsとは 以下はCDK PatternsのGitHubリポジトリからの引用です。 CDK Patterns houses an opensource collection of AWS Serverless archi
FRONTEND CONFERENCE FUKUOKA2019の登壇資料です
KubeFest Tokyo 2020は、Kubernetes を利用している人、これから導入したい人が新しいことを学んだり、ネットワーキングすることを狙いとして開催するワンデイのオンラインイベントです。Kubernetes環境におけるCI/CDの問題をOpen Policy AgentとSpinnakerを導入することで解決する方法について、メルペイの山下氏が話をしました。前半はメルカリのマイクロサービスアーキテクチャについて。 自己紹介とアジェンダ 山下慶将氏（以下、山下）：「Open Policy AgentとSpinnakerで実現するマイクロサービスの安全な継続的デリバリー」というタイトルで発表いたします。よろしくお願いします。 はじめに自己紹介します。山下慶将と言います。Twitterは@_k_e_k_eでやっているので、よかったらフォローしてください。今はメルペイSREに所属
｜DMM inside
[AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャの設計パターン 資料及び QA 公開 | Amazon Web Services
Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャの設計パターン 資料及び QA 公開 先日 (2020/03/25) 開催しました AWS Black Belt Online Seminar「AWSにおけるマイクロサービスアーキテクチャの設計パターン」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200325 AWS Black Belt Online Seminar AWSにおけるマイクロサービスアーキテクチャの設計パターン AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Amazon API Gateway は複数のバックエンドを統合する機能は持たないと思います。その意味で BFF パターンの実装に位
![[AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャの設計パターン 資料及び QA 公開 | Amazon Web Services](https://cdn-ak-scissors.b.st-hatena.com/image/square/086852b76948f8957392ddb6df5e02bc042a3547/height=288;version=1;width=512/https%3A%2F%2Fd2908q01vomqb2.cloudfront.net%2Fb3f0c7f6bb763af1be91d9e74eabfeb199dc1f1f%2F2020%2F03%2F30%2FThumbnail-3.png)
サーバーレスアーキテクチャの数理的理解と分析 #devsumi / Developers Summit 2023 Summer
Developers Summit 2023 Summer で使用したスライドです。 サーバーレスアーキテクチャは強力ですが、同時に冪等性やトランザクションなど特有の考慮事項が必要であり、高い設計力が求められます。ところで、安全なプログラムを書く上で、静的型付き言語は広く利用されていますね。型はいわば実行前に間違いを検出できる仕組みであり、その背後には「プログラムの正しさ」を厳密な数式で記述し分析する理論が存在します。では、同様に「サーバーレスの正しさ」も厳密な数式で記述することは可能でしょうか？本講演ではAWS Lambdaを用いた設計を例として取り上げながら解説します。 イベント概要：https://event.shoeisha.jp/devsumi/20230727/session/4486/ ブログ記事：https://ccvanishing.hateblo.jp/entry/20
ソフトウェアアーキテクチャはシステムの成功に不可欠な要素であり、ソフトウェア開発者にはこの分野における効果的なスキルが求められる。しかし、その学習資料はまだ十分ではないのが現実である。株式会社えにしテックの代表取締役 島田浩二氏は、ソフトウェアアーキテクチャに関する書籍を多数翻訳している。Developers Summit 2023 Summerに登壇した島田氏は、数々の書籍から学んだソフトウェアアーキテクチャの重要なエッセンスを紹介した。 ソフトウェアアーキテクチャとは？ 3つの定義を紹介 島田氏は2009年に株式会社えにしテックを設立。2011年からは一般社団法人日本Rubyの会の理事を務めている。島田氏が翻訳に携わった書籍には、『進化的アーキテクチャ』『ソフトウェアアーキテクチャハードパーツ』、『ソフトウェアアーキテクチャの基礎』『Design It!』（いずれもオライリージャパン）
まずは基本中の基本 EC2とVPC 2019年6月に開催されたAWS Summit Tokyoでは、数多くのブレイクアウトセッションが用意され、どの会場も多くの聴衆が耳を傾けていた。ここでは「Architecting for the Cloud 2019 クラウドにおけるアーキテクチャの設計原則」のポイントをまとめておこう。解説はAWSに入社して8年目となるアマゾン ウェブ サービス ジャパン ソリューションアーキテクト 荒木靖弘氏。 アマゾン ウェブ サービス ジャパン ソリューションアーキテクト 荒木靖弘氏 まずは基本中の基本としてEC2とVPCから。AWSで「サーバー」と言えばEC2（Amazon Elastic Compute Cloud）。荒木氏は「便利に使える仮想サーバー」と言う。規模や用途に応じて多数のインスタンスタイプが用意されている。EC2はAMI（Amazon Mach
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
私が考えるマイクロサービスアーキテクチャ
はじめに 以前に、マイクロサービスアーキテクチャにゼロから挑んだ開発経験から、私が現時点で考えるマイクロサービスアーキテクチャを書いてみる。前回はAWSで構築したがAWSに限定せず汎用的に表現してみたいと思う。 前提 例として、社員の勤怠と有給の管理ができるようなwebのSaaSプロダクトを考える。 ここでいうプロダクトとは商品として販売できる最小の単位とする。 境界づけ まずは、プロダクトを5つの機能に分類する。 認証・・・認証を行うIdP。ユーザー固有のIDを管理するユーザーディレクティブを持つ。 ユーザー・・・認証されたユーザーと権限の紐付きを持つ。 権限・・・ロールとポリシーによる権限を設定する。「ユーザー」「権限」「勤怠」「有給」というサービスそれぞれに個別の設定ができる。 勤怠・・・勤務の開始と終了を管理できる。 有給・・・有給の付与、消化、残日数の管理ができる。 パターン1：
エンジニアはプログラミングの力で世界を変えることができる 篭橋裕紀氏（以下、篭橋）：ありがとうございます。他に質問したい方はいますか？ 次のところのほうがもう少し詳しくいろいろな話が聞けるかなと思うので、そしたらテーマ2に。城倉さんお願いします。 城倉和孝氏（以下、城倉）：じゃあテーマ2ですね。先ほどのコースが3つあります。じゃあそれになるためにまずどうしたらいいのかという話ですが、みなさんはエンジニアなので、やはりエンジニアとしてそれなりに大成するということは大事だと思います。 例えば、「VPoEになります」と言っても、やはりエンジニアの気持ちがわからないとマネジメントもできないですよね。だから、まずは「イケてるエンジニア」を目指してほしいなというのがテーマ2になります。 今わりと「エンジニアが不足してる」という声もありますが、なんでかという話を少し話すと、まず時代背景があります。DXっ
MLOps: 機械学習における継続的デリバリーと自動化のパイプライン | Cloud アーキテクチャ センター | Google Cloud
デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。
急速に進化するテクノロジーの世界において、Intelは、最近、コンピューティングの未来に革命をもたらすことを約束する簡素化された新たな64ビットモード専用のアーキテクチャ「x86S（仮称）」のビジョンを発表した。 将来のIntelアーキテクチャは64ビット専用になりレガシーサポートが終了するIntelの新しいx86Sは、現代のコンピューティング・システムがますます複雑化していることへの対応策だ。テクノロジー・ユーザーの要求が高まり続ける中、より効率的でパワフル、かつ合理的なコンピューティング・ソリューションへのニーズも高まっている。x86Sは、このようなニーズに対応し、テクノロジーの未来に向けた青写真を提供することを目的としている。 Intelは、レガシーな32ビットと16ビットモードのサポートを取り除くことに機会を見出し、64ビットのみのアーキテクチャを提案している。これは、不要なレガシ
AWS黎明期のベストプラクティスを改めて読み返すことで、クラウドのためのアーキテクチャー大原則を再確認する | DevelopersIO
西澤です。最近AWSの進化が凄まじすぎて、そもそもついていけない選択肢が多すぎるし、設計難しいよなーって思うことが増えています。もうAWS上で動かすことができないシステムはほぼ無くなりつつあるのが現状だとは思いますが、それでもやはりクラウドとの親和性が高いシステムとそうでないシステムがあることも事実だし、そもそもの大原則を復習することで、本来想定されていたあるべき姿を抑えておくことには意味があるんじゃないかと考えています。そこで、私が初めてAWSを知ったときに衝撃を受けた資料を読み返してみたところ、シンプルで非常に重要な原則が書かれていることを再確認できたので、ここで改めてご紹介したいと思いました。 ご紹介したい資料 私がクラスメソッドにジョインしたときに書いたブログでもご紹介させていただいたのですが、今回ご紹介するのは、当時AWSのエバンジェリストだった玉川さん、ソリューションアーキテク
「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編もエンジニア教育も一つ一つ丁寧に積み上げてモダナイズを進めた話｜CTOロングインタビュー - MonotaRO Tech Blog
独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹
WebエンジニアとWeb技術とシステムの話 (sadnessOjisanのWebサーバーアーキテクチャ進化論2023を読んだ感想) - inductor's blog
sad記事の勉強と実践のボリュームがすごい https://blog.ojisan.io/server-architecture-2023/ を読んで、その前身とも言える https://blog.yuuk.io/entry/2015-webserver-architecture を含めてこれらのような記事を書く知識や経験が僕には無いから素直にすごいと思った。ただ、その一方でこの内容を普通に理解できる「Webエンジニア」はどのくらいいるんだろう？というのも同時に気になった。 ゆううきさんの記事は「序論」とあるがWebエンジニアとしてキャリアを積む人間が「序論」として読むには文量や背景知識が重すぎると正直思うし、システム・計算機工学を勉強した人間が背景に感じ取れる。事実、sadさん(おじさん)も昔は内容が分からなかったと本人記事内で言及しているため、僕の気のせいではないと思う。じゃあsad版
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社 の吉井です。 今回は AWS Perspective を紹介します。 Developers.IO を読んでくださっている方々はシステム担当者(アプリもインフラも)が多いと想像しています。 みなさまは詳細度、解像度の高低はあれどアーキテクチャー図を作成していることと思います。 個人的な意見ですが、作成ドキュメントの弱点は ”更新されないことがある” ことにあると考えています。 変更管理を細かく行っている企業ならそんな心配は要らないかもしれませんが、大抵の場合システム稼働日数が増えれば増えるほどドキュメントは置いてけぼりになりがちです。 それはある意味理解ができてドキュメントは無くてもシステムは動くので、システム構成変更時のドキュメント更新の優先度が下
エンジニアリング組織アーキテクチャの調査と設計要点に対する考察 / Investigation of engineering organization architecture and consideration of design points
第5回 Web System Architecture 研究会 (WSA研) の発表資料です。 https://websystemarchitecture.hatenablog.jp/entry/2019/07/30/172650
こんにちは。ティアフォーでWebサービス開発を担当している池谷です。 世の中はコロナで自粛モードが続いていますが、ティアフォーではリモートワークを活用し日々の業務に柔軟に取り組んでいます。 さて、私の所属するWebチームでは、オープンソースの自動運転OS「Autoware」を利用した多種多様なサービスを開発しています。その中でも代表的なサービスに「FMS」という運行管理サービスがあります。今回は、当サービスを開発してきた振り返りとして、主にドメイン駆動設計によるアーキテクチャの最適化に纏わるトピックについてお話したいと思います。 What's FMS? ティアフォーのFMSの注目機能 オンデマンド配車モデル 巡回走行モデル ベストプラクティスを求めて FMS開発における試行錯誤 浮上していた課題 開発手法のアプローチ ドメイン駆動設計 モデリングの実践 設計・実装面のアプローチ クリーンア
自社サービスにおいてどのようにアーキテクチャと技術を活用するかについて、基本的な考え方をお話ししました。 https://event.shoeisha.jp/devsumi/20230209/session/4133/
概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立
WebアプリケーションにGoの並行処理アーキテクチャを導入してSLOを改善し、WebAPIを100倍速くした話 - スタディサプリ Product Team Blog
こんにちは。スタディサプリの小中高プロダクト基盤開発グループでProduct Platform Engineer兼テックリードをやっている@tooooooooomyです。 今回は、WebアプリケーションにGoの並行処理機構を導入してSLOを改善し、WebAPIを100倍速くした話をしたいと思います。 前提条件 システムを0から作らない場合、アーキテクチャの改善の際には前提条件が付きものです。そこでまずは今回のシステムの前提条件をお話します。 対象となるシステムと、アーキテクチャ 今回対象とするシステムは、ここでは security-tracker と呼び、Webアプリケーション本体はGoで書かれています。 スタディサプリの各アプリケーションにおけるユーザーのログ1を、Amazon Kinesis Firehoseを通して、リクルート全体のセキュリティチームが管理するS3バケット(スタディサ
Arm入門勉強会とは、macOSがArmに移行したこの機にArmアーキテクチャでのプログラミングについて入門するソフトウェアエンジニアのための会です。OS開発に必要なArmの低レイヤーなプログラミングについて、金津穂氏が共有しました。前半はArmの実行モデルと割り込みについて。全2回。 概要と自己紹介 金津穂氏（以下、金津）：「AArch64とOS入門」ということで金津が発表いたします。 はじめにですが、「これからArmでOSを自作したい！」という人向けのまとめ資料になります。なので、すでにArmでお仕事している人、とくに組み込み向けだったりとかすでにOS開発とかしている人にとってはもう既知の情報しかない。あと、リファレンスマニュアルを自分で読める人にとっては、それを読んだほうが確実な情報が手に入るんじゃないかなと思います。 Armと題してますけど、基本的にはAArch64だけにします。A
【アーキテクトの重要な仕事】ビジネスの意図をアーキテクチャで表現する - エス・エム・エス エンジニア テックブログ
@sunaot です。『「継続性アーキテクト」という生き方』や『アーキテクトを目指すエンジニアの最短ルート』が興味を持ってもらえたので、この記事ではアーキテクトの仕事の重要な一部だと考えている「ビジネスの構造をアーキテクチャで表現する」ということについて書いてみます。 ビジネスの構造と書いてしまうと、業務のモデリングの話かなと思われるかもしれません。実際、設計手法について書かれている書籍では業務のモデリングの話が中心です。その時代の前提は、要求を持っている人としてのユーザーがいて、業務があって、そのシステム化をしていくというものでした。現在、サービス開発をしていくという中で直面している仕事はやや性質が変化していると感じています。正解となるサービスの姿というものはなく、やっているビジネスの状況やユーザーの関心も変化する中でサービス開発をし、サービス自身も変化をしていきます。サービス開発年代の
はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細（フレームワークやデータベース）を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ
書き始める とりあえずチュートリアルを一周しました。 https://github.com/k1LoW/ndiag/blob/main/docs/tutorial.ja.md チュートリアルの順に、nodesを書いてみてndiag doc --rm-dist、networksを書いてndiag ...、relationsを書いて以下略、とするのが良さそうです。 アイコンのキーはndiag list iconsで表示できるので、これを見ながらndiag.ymlに書き込んでいきます。 VSCode ExtensionsでMarkdown Preview Enhancedをインストール。 Previewを見ながらndiag.ymlを書いては生成、書いては生成します。 とりあえず --- name: Sample AWS web service docPath: docs/arch views:
DynamoDBによるOutboxパターンとCDCを用いたCQRSアーキテクチャの実装〜ZOZOMOでの取り組み - ZOZO TECH BLOG
こんにちは。ブランドソリューション開発部プロダクト開発ブロックの岡元です。普段はFulfillment by ZOZOとZOZOMOのブランド実店舗の在庫確認・在庫取り置きサービスの開発、保守をしています。 本記事では、ブランド実店舗の在庫確認・在庫取り置きサービスで実装したCQRSアーキテクチャについて紹介させていただきます。 CQRSの実装においては、データベース（以下、DB）分割まで行い、コマンド側DBにはAmazon DynamoDB（以下、DynamoDB）、クエリ側DBにはAmazon Aurora MySQL（以下、Aurora MySQL）を用いています。また、コマンド側DBとクエリ側DBの橋渡しを担うメッセージングにおいてはOutboxパターンと変更データキャプチャを用いました。DBとメッセージングシステムへの二重書き込みを避けることで障害などのタイミングで顕在化する潜在
DX時代のITアーキテクチャー、7階層ですっきり理解
DX時代に求められるITアーキテクチャーの構成は複雑なことが多く、必要な要素技術や設計・開発手法も多岐にわたる。その全体像を把握するのは困難に思えるが、以下のように7階層に分けて考えると理解しやすい。 ●DXを支える7階層のITアーキテクチャー （1）チャネル層 （2）UI／UX層 （3）デジタルサービス層 （4）サービス連携層 （5）ビジネスサービス層 （6）データサービス層 （7）データプロバイダー層 今回はこの図を基に、7階層のそれぞれの特徴とDX移行時に押さえるべき要素技術や仕様、よくある課題について順番に見ていこう。 （1）チャネル層はユーザーとの最初の接点 ユーザーとサービスとの最初の接点となる部分の階層。パソコン、スマートフォン、タブレットなどの端末、そこからアクセスするアプリケーション（Webブラウザー、チャットボット、SMSなど）の他、コールセンターなどの顧客サービスもチ
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
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が最近リリースされ、重要な変...
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dodaアプリを支える技術とアーキテクチャ・設計思想 - techtekt
"技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita
フロントエンドにおけるアーキテクチャとの向き合い方
メルペイのエンジニアが教えるマイクロサービスアーキテクチャを安全かつ継続的に運用する方法
決済基盤でAWS CDKを使ったサーバーレスアーキテクチャ構築 - DMM inside
『ソフトウェアアーキテクチャの基礎』島田浩二氏が語る、エンジニアが最初に知っておくべきアーキテクチャリテラシー
AWSのアーキテクチャの基本をアップデート 押さえておくべき7つの原則
流行りのBFFアーキテクチャとは？｜Offers Tech Blog
美しいコードは“シンプルで無駄がない” イケてるエンジニアが大事にする「良いコード」「良いアーキテクチャ」とは
Intel、64ビット専用アーキテクチャ「x86S」のビジョンを公開 | TEXAL
AWS アーキテクチャー図 構成図を自動生成するソリューションを紹介します | DevelopersIO
ドメイン駆動設計による運行管理システムのアーキテクチャの最適化 - TIER IV Tech Blog
継続的なサービス発展を支えるアーキテクチャと技術 / Developers Summit 2023
TypeScriptでクリーンアーキテクチャを実践する
東工大、IoT向けCPUアーキテクチャ「SubRISC+」。エネルギー効率3.8倍
OS開発に必要なArmアーキテクチャとは part.1 実行モデルと割り込み
Go言語によるクリーンアーキテクチャの実装例紹介
ndiagでAWSのアーキテクチャドキュメントを書く
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
LinkedIn、システムの複雑性低減のためにLambdaアーキテクチャを廃止