React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
ドメイン駆動設計の実践
2024年7月20日に発売された『ドメイン駆動設計をはじめよう』の概要説明と、ソフトウェア開発現場での活用方法。 ①何が書いてあるか？ ②事業活動の分析（１章）⇒設計判断 ５章、6章、7章、８章、10章 ③業務知識の発見（２章） ④事業活動の複雑さに立ち向かう（３章） ⑤区切られた文脈どう…
Google Cloud の CDC サービスを活用した請求フローの構築 - Repro Tech Blog
はじめに こんにちは。新規事業のプロダクトマネジメントを担当している taison です。 先日、顧客への請求金額を算出するために日々実行しているデータフローを刷新しました。 その際に Datastream という Google Cloud が提供する CDC サービスを活用したことで、構築・運用が楽になったのでご紹介します。 なお今回は開発にご協力いただいている 株式会社 Rabee の abyssparanoia さんの提案・検証があって実現したので、ここで感謝させていただきます。 全体像 それまではとある BI ツールを活用して、請求根拠となるデータを各内容にあわせて出力するデータフローを組んでいました。 下図のように、プロダクトの RDB（アプリケーションデータ）そのものに直接接続し、BI ツールで生成したクエリを定期的に実行することで要件を満たしていました。 ただ、おかげ様で事業
データ詰め替え戦略 - kawasima
このSpring Bootを使ったクリーンアーキテクチャの例は、データの詰め替え過剰にみえる。 https://www.baeldung.com/spring-boot-clean-architecture これだけのモデルと詰め替えが必要なのだろうか? 『Get Your Hands Dirty on Clean Architecture 』にこのマッピング戦略(詰め替え戦略)が書かれている No Mapping (レイヤ間でモデルを共有し、詰め替えをしない) 2-way Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しは上位レイヤが詰め替えの責務を負う) Full Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しには専用のモデルを使う) またこの戦略のどれを選ぶかの基準は『Balancing Coupling in Software Design
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
DDDを実践するための手引き（ドメインイベント編）
ドメインイベントを扱う実装は様々な流派があり、本記事ではなるべく一般的なものを取り上げたいと思っていますが、あくまで一例です。 実装例は Kotlin を使っていますが、他の言語でも同様の実装が可能です。 ドメインイベントとは イベントとは「過去に発生した出来事」であり、ドメインイベントは「ビジネスドメイン上で発生した重要な出来事を表すメッセージ」です。 （例: チケットが割り当てられた、注文がキャンセルされた） ドメインイベントはシステム内の状態の変化（=集約の状態の変化）を表現するものであり、通常は集約がドメインイベントの発生源となります。 用途 ドメインイベントは主に次のような目的で使用されます。 1. イベントの発生を起点に、別の処理をトリガーする ドメインイベントは、システムの異なる部分間を連携させるために使用されます。 ドメイン上の要件として「...したら...する」のようなフ
技術的負債になりかけていた機能をリアーキテクティングしたら、めちゃくちゃ改善した話 - カミナシ エンジニアブログ
ソフトウェアエンジニアの 鈴木 (@szk3) です。 先日、カミナシにおいて古くから存在する１つの機能をリアーキテクティングしました。 その結果、処理時間は4分の1以下、コストは90%程度削減 と大きな成果を出すことができました👏 本記事では、その機能が抱えていた課題に対しどのような改善のアプローチをして上記の結果に結びついたのか？について共有します。 Excel変換とは 今回、リアーキテクティングの対象となった機能は、カミナシに帳票として記録されたデータをExcel形式に変換して出力する機能です。 これを、”Excel変換” と呼んでいます。 Excel変換は、カミナシのサービスの中でも比較的古くから存在する機能です。 ここ数年での利用ユーザーの増加と共に、設計当初のシステムアーキテクチャが技術的な負債となっている状態でした。 Excel変換の課題 まず最初に、設計当初のアーキテクチ
Modular Monolith はどの辺りから考え始めるものなのか - id:onk のはてなブログ
モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。 モジュラーモノリスとは モジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ（？）を読めば良いんじゃないか。 有名なのは Shopify のヤツ。 モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。 モジュラーに移行するタイミング 僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。 世の中で見つけたモデル
RustでClean Architectureを実装してみる
はじめに RustでWebアプリケーションのGraphQLバックエンドを実装してみました。その中で、できるだけClean Architectureに沿うように実装してみたので、得られた知見を公開してみたいと思います。 資料に基づきできるだけ正確な記述を目指していますが、誤りもあるかもしれません。また実装から少し時間を空けて執筆しているので、忘れている部分も多く不正確なことが書いてあるかもしれません。 Clean Architectureとは 以下のブログでRobert C. Martin（通称Uncle Bob）によって提唱されたアーキテクチャです。 その後本人により書籍も出版されました。日本語にも翻訳されています。 歴史について簡単に 多層アーキテクチャ (Multitier architecture) というものはかなり昔から考えられていたようです。初出についてはよくわからないのですが
Architecture of an early stage SAAS | Feelback Blog
IntroductionIn this article I describe a simple architecture for an early stage SAAS. As a solo founder, I report some choices made to launch Feelback, a small-scale SAAS for collecting users signals about any content. This article will cover the technical side of designing and running a simple SAAS. It will also include some details about coding and evolving the initial feature set ready at launc
なぜ？ 「Suica」がサーバ型に移行する理由 25年近く稼働する“安全神話”の象徴に何が
なぜ？ 「Suica」がサーバ型に移行する理由 25年近く稼働する“安全神話”の象徴に何が（1/3 ページ） 4月4日昼頃、一部店舗でSuicaを含む交通系ICカードなどFeliCa系電子マネーが利用できなくなる障害が報告された。筆者はちょうどその時間帯にイオン系の「まいばすけっと」で買い物をしていたが、「この時間、交通系ICカードが利用できません」との告知でレジ待ち行列が混乱している様子が見受けられた。このほか、自販機での電子マネー決済ができないという報告も多数散見され、それなりの影響が出ていた印象だ。 同日中にJR東日本メカトロニクスから「クラウド型マルチ電子マネー決済システムにおける不具合発生につきまして」というプレスリリースが出されており、処理センターのハードウェア障害であることが報告された。確認した範囲で、同社が日本カードネットワークと共同運営している「J-Mups」における障害
“1つの独立して動く要素”の内部を整理し直す 「改めて整理するアプリケーション設計の基本」で伝えたいこと
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。まずは本セッションの内容について説明します。 大嶋氏の自己紹介 大嶋勇樹氏：では、「改めて整理するアプリケーション設計の基本」ということでお話しします。（スライドを示して）最初に私の自己紹介ですが、名前は大嶋勇樹と申します。最近はよく“しまさん”とか“しまちゃん”とか、そんなふうに呼ばれることが多いです。 キャリアは新卒で都内のあるIT企業に入って、その後フリーランスエンジニアとして独立して、今は会社を設立していろいろしています。今は実務に就き始めぐらいのエンジニアの方のスキルアップのサポートで、研修や勉強会、あと最近は「Udemy」講座をいくつか作ったりしています。 今日の発表に関連する
本当は怖い、逆コンウェイ戦略 | フューチャー技術ブログ
アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
転職活動でいろんな会社のマイクロサービスと組織を見聞きして思ったこと - Runner in the High
転職活動でいろんな会社のエンジニアの人と話して思ったことをマイクロサービスの観点で備忘録がてらメモしておく。 よくあるマイクロサービスの分割軸として、業務機能、ユースケース（動詞）、リソース（名詞）あたりが一般的だが、これらどれもがドメインを構成する要素であるため、マイクロサービスに分割してしまうと結果的にソフトウェアの形がビジネスルールの変化を制限してしまうケースの方が多い気がしていた。実際、規模の小さい開発組織でマイクロサービスやってみました〜からのツラミはそういうのが多いイメージで、よくある「マイクロサービスやったけど逆に開発遅くなった」みたいなとこは上で挙げたような粒度の切り方をしている印象がある。 この件に関して、去年末の転職活動のタイミングでいろいろな人に話聞いてみた結果、実際にマイクロサービスでうまくやっていそうな組織は、上で書いたようなドメインを構成する要素でマイクロサービ
アーキ部：強いて言えば「集約どう実装するのかな、を考える」会に参加してきた！ - そこに仁義はあるのか(仮)
kawasimaさん主催のアーキ部に参加しました！ architect-club.connpass.com テーマの発端になったツイート 部門に社員を配属するとか、カートに商品追加するとか、コレクションを集約としてアイテムを追加する訳だが、件数多くいちいちコレクション全体をメモリにロードしてられないこともある(というかそういうケースの方が多いのでは?) 。そういう時にどういう設計パターンが考えうるか、まで論じて欲しい。— kawasima (@kawasima) 2023年1月13日 これまでドメイン駆動設計やクリーンアーキテクチャとかを勉強してきましたが、このツイートを見て「実際に『性能』を意識してコードを書いていくってどうしたら良いんだろう？」と謎になりました。 この勉強会では、『性能』は重視しつつ、どうやってドメインをコードに表現していくのか、というお話をkawasimaさんからして
Twitter を作るのはなぜ難しいのか
Fumihiko Shiroyama @fushiroyama 父、博士課程 Software Development Engineer @Adobe / ex-@Microsoft, ex-@amazon All opinions are my own. note.com/fushiroyama/ Fumihiko Shiroyama @fushiroyama Twitterみたいな緩いつながり、TLひとつ実装するだけでも普通のウェブシステムみたいなクエリでは取れなくてちょっと考えれば非常に複雑なシステムであることは明白だし、システムアーキテクチャの試験の定番トピックだったりするので「誰でも作れる」とか「簡単」みたいなのはご指摘申し上げたくなる Fumihiko Shiroyama @fushiroyama 昔つぶやきましたが例えばこの記事を読むと分かりやすいです。 twitter.co
Why Twitter Didn’t Go Down: From a Real Twitter SRE
Twitter supposedly lost around 80% of its work force. What ever the real number is, there are whole teams with out engineers on it now. Yet, the website goes on and the tweets keep coming. This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I’d like to explain my little corner of Twitter (though it wasn’t so little) and some of
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
継続的なサービス発展を支えるアーキテクチャと技術 / Developers Summit 2023
DIP(依存性逆転の原則)を守っていない話