ディメンショナルモデリング勉強会を実施しました - 10X Product Blog
データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。 最近、社内でディメンショナルモデリング勉強会を行なったですが、なぜ勉強会を行なったのか、どのように行なったのか、勉強会を行なった結果何が得られたかについてまとめます。 ディメンショナルモデリング勉強会開催の背景 勉強会の進め方やスコープ 勉強会の参加者 勉強会で学んだ内容 Four-Step Dimensional Design Process キーの設計について 複数スタースキーマを適切に利用し、ファントラップを避ける コンフォームドディメンション まとめ: 勉強会で得られたもの ディメンショナルモデリング勉強会開催の背景 前回のエントリにまとめた通り、10Xのデータマネジメントの課題の中でも「データウェアハウジングとビジネスインテリジェンス」は優先度が
プレミアムプランの状態管理と決済ハンドリングの難しさ｜tsusowake
はじめにこんにちは、PIVOTでソフトウェアエンジニアをしている裾分です。PIVOTは2024年2月にアプリ・Webを本格始動しました。私はPIVOTにジョインして以降、サブスクリプション機能の開発をしてきたので設計の概要と決済プラットフォームが係る実装の難しさについてまとめてみました。 本題冒頭のリリースの通り、PIVOTはYouTubeからプロダクトに集中するにあたり、サブスクリプション機能をリリースしています。 サブスクリプションを実装するにあたり考慮すべき点として、以下の状態を考慮する必要があります。 自サービスで管理する状態 ユーザーのサブスクリプション ユーザーのプラン 他サービスで管理する状態 ユーザーへの課金を行うプラットフォームに登録されているサブスクリプションの状態 決済状態（成功 | 失敗 | …） PIVOTの場合では、決済プラットフォームとして App Store
請求関連テーブルのスキーマ変更をした話 - Feedforce Developer Blog
以前に アプリケーションを停止させずにRDBのスキーマ変更する話 を書きました。 developer.feedforce.jp 今日は、その実践編というか、実例として EC Booster というサービスで請求関連テーブルのスキーマを変更した話をしようと思います。 はじまりのテーブル 元々、 EC Booster の請求を管理するテーブルは、このような形でした。 create_table "monthly_charges", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t| t.uuid "shop_id", null: false t.integer "year", null: false t.integer "month", null: false t.datetime "created_at"
React のルール – React
様々な概念を表現する方法がプログラミング言語によってそれぞれ異なるように、React にも、理解しやすい方法でパターンを表現し高品質なアプリケーションを産み出すための慣用的な記法、ないしルールが存在します。 このセクションでは、自然な React コードを書くために従うべきルールを説明します。自然な React コードを書くことで、安全で整理されており、組み合わせ可能なアプリケーションを作成することができます。以下に挙げる特性により、アプリは変更に対して頑健になり、他の開発者やライブラリやツールと連携しやすくなります。 以下のルールは React のルールとして知られています。これらを守っていないならアプリにバグがある可能性が高い、という意味で、これらは単なるガイドラインではなくルールです。またこれらを守らない場合、あなたのコードは不自然で、理解や推測が難しいものになるでしょう。 Reac
データモデリングでドメインを駆動する | プログラミング・システム開発,開発技法・ソフトウェアテスト・UML,開発技法・開発管理 | Gihyo Direct
データモデリングでドメインを駆動する ──分散／疎結合な基幹系システムに向けて 2024年2月24日紙版発売 杉本啓 著 A5判／400ページ 定価3,740円（本体3,400円＋税10%） ISBN 978-4-297-14010-6 この本の概要 本書のテーマは「データモデリング」と「基幹系システム」です。 Web上で台頭しつつある新たなビジネスは，新たな基幹系システムを必要としています。一方，既成ビジネスでは，モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。 基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があります。そのデザイン，つまりデータモデリングがいずれの取り組みにおいてもカギですが，データモデリングが真価を発揮するには，その知識体系を現代的に仕立て直す必要があります。 本書では，「活動のシステム」と「経営管理のシステム」という線引
Databricks レイクハウスプラットフォームでのデータウェアハウスのモデリングと実装
レイクハウスは、データレイクとデータウェアハウスの長所を組み合わせた、新しいデータプラットフォームパラダイムです。多くのユースケースやデータプロダクトを格納できる、大規模なエンタープライズレベルのデータプラットフォームとして設計されています。データレイクとデータウェアハウスを統合した、単一のエンタープライズデータリポジトリとして使用することができます。 データドメインリアルタイムストリーミングのユースケースデータマート異種データウェアハウスデータサイエンス機能ストア、データサイエンスサンドボックス部門別のセルフサービス型分析サンドボックスユースケースの多様性を考えると、レイクハウスのプロジェクトによって異なるデータ整理の原則やモデリングテクニックが適用されるかもしれません。技術的には、Databricks レイクハウスプラットフォームは、多くの異なるデータモデリング形式をサポートすることが
UbieにおけるGo言語のエラーハンドリング
背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に本番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました
新しいモデリング手法: EventStormingをはじめるための準備 - yoskhdia’s diary
EventStorming (イベントストーミング) というモデリング手法があります。 www.eventstorming.com EventStorming is a flexible workshop format for collaborative exploration of complex business domains. EventStormingは、複雑なビジネスドメインを協同的に探求するための柔軟なワークショップ形式のひとつです。（意訳） 考案者はAlberto Brandolini氏で2013年にはブログに最初の投稿がされています。 海外での認知度は高く*1、Eric Evans氏のプレゼンテーションの中でも強力な手法であると言及*2されています。 近々、この手法を試せる機会が来そうなので、そのやり方について（私見を交えつつ）まとめてみるエントリです。 注意 現在進行系
イベントストーミングを実施して、3日間で境界づけられたコンテキストを定義した話
この記事は何？ 2024/3/5~2024/3/7にAWS ソリューションアーキテクトの福井さん、金森さんの助力を得てイベントストーミングを実施しました。 そのイベントストーミングでどういうことを実施して、どういう成果が出たのか、得た知見や学びについて書いていきます。 背景 前提として、弊社のバックエンドのアプリケーションの構成としては、いわゆるモノリスな構成となっております。2018年の創業からsnkrdunkの成長に合わせて、アプリケーションもイケイケドンドンと実装が追加され成長していきました。2022年ごろにはグローバル向けのアプリも提供し始めました。 その勢いのままに弊社はさらに事業を成長させ、時価総額1,000億規模のIPOを実現しようとしています。 IPOを目指すにあたって、システムでは大きな問題が2つあります。 機能開発の速度が低下しつつある JP側で開発した機能をGE側で再
データベースの在庫の持ち方をビットで管理してる話 - 一休.com Developers Blog
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください！ https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
バッチ処理について考える - Qiita
TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万～数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ？ネットに本にも答え載ってないよ？低レイヤも意識しないと動かないよ？ 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本
設計の知識と技能で駆動するソフトウェア開発
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化：基本となる４つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成（参照モデル） コア（中心） ポート（境界） アダプタ（周辺） ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア（中央） 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター（周辺） 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン
大規模データを扱う現場でどんな変化が？ Snowflake導入5社のデータ基盤アーキテクチャと設計意図 - Findy Tools
公開日 2024/03/11更新日 2024/03/12大規模データを扱う現場でどんな変化が？ Snowflake導入5社のデータ基盤アーキテクチャと設計意図 スケーラビリティやデータ活用までのリードタイム、価格面での懸念に応える製品として注目を集めるSnowflake。特に大規模なデータを取り扱う現場では、Snowflake導入によってどんな変化があるのでしょうか。 本記事では、前回の第一弾でご紹介したChatworkさん、delyさん、GENDAさん、スターフェスティバルさんに引き続き、第二弾として大規模データを取り扱う5社に、データ基盤の設計思想やデータチームの方針にも触れながら、Snowflake導入の背景や効果を伺いました。 ■目次 ・株式会社Algoage ・株式会社GROWTH VERSE ・株式会社マイナビ ・ノバセル株式会社 ・株式会社セゾン情報システムズ 株式会社Alg
サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
ID生成方法についてあれこれ
ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
React Server Components と GraphQL のアナロジー
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う（何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので）。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
レイヤードアーキテクチャでデータを作成・編集するときの設計が分からん
定期的に DDD やクリーンアーキテクチャなどを題材にした記事が盛り上がっているのを見ていると、いま長年の疑問を書けば誰か答えてくれるのではと思って書いてみる。 何に困っているかというと、 いわゆるレポジトリ層が持つ create/update 関数の引数は Entity で待ち受けるべきか、プレーンなオブジェクトで待ち受けるべきか分からない ユーザーから POST Body されたデータにはビジネスルールを適用させるべきか（= 一度 Entity を作るべきか）分からない だ。 Entity を作らない場合、いわゆるトランザクションスクリプトと呼ばれているものに近づく。 そしてトランザクションスクリプトには結構否定的な意見も見られる。 しかし、自分は Entity を作ることが必ず正解とは思えず、レイヤードな設計とトランザクションスクリプトを組み合わせる設計の余地もあると思っていて、トラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
