丁度ええ! ロギング - kawasima
2025/4/24に開催した #アーキ部 『丁度ええ! ロギング』の内容を編集したものです。 ロギングにまつわる問題の構造 ロギングにまつわる現場でよく見られる問題には以下のようなものがあります。 ロギングガイドラインを定義して、開発者に周知し実装してもらったが、実際運用してみると、役に立たないログが多すぎる。 担当者が異なると、ログ出力する粒度が微妙に異なり、解析に時間がかかる。 ログの形式や内容が統一されておらず、分析ツールでの活用が難しい。 ロギングベストプラクティスは探すといくつか見つかります。 https://www.dataset.com/blog/the-10-commandments-of-logging/ https://betterstack.com/community/guides/logging/logging-best-practices/ https://new
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパター
DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパターンです。 よく依存性の逆転・DIと一緒に語られますが、くまぎさんがおっしゃる通り余計にインターフェースを切るのはイケてないと感じます。また、DI抜きにしても、リポトリパターン由来の様々な問題（N＋1やバルクアップデート、管理画面用のメソッド生やしたくなる問題など）に対する解決策として提示さ
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/c6411e973b8b4ad8b410c7e0790c010ec563e1ef/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F6447e2a377c26d351b8110811e79b907e32094d6%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20210306%252F20210306230551.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即破綻します。 理解できない人はどこに処理を書いてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Memory and Performance: Latency
エンジニアとしての価値は、最新技術を追うだけ・既存技術を知っているだけは上がらない「重要な変化と重要でない変化を見極めて、普遍的な基礎も磨きつつ、潮流を変えるような技術ならキャッチすべき」
継続的なサービス発展を支えるアーキテクチャと技術 / Developers Summit 2023
DIP(依存性逆転の原則)を守っていない話