bmf-tech.com - 複数のテーブルに多対1で紐づく時のテーブル設計のアプローチについて
概要複数のテーブルに対し、多対1でテーブルが関係付くときのテーブル設計のパターンについてまとめる。 データ設計以下のようなケースのデータ設計を例とする。 issues id title pullrequests id title comments id content commentsがissues、pullrequestsのどちらに対しても多対一で関係付くようなケース。 ポリモーフィック関連 issues id title pullrequests id title comments id content target_table target_id commentsにtarget_tableとtarget_idというカラムを追加し、issuesとpullrequestsのどちらに結びつくか判断させようとするテーブル設計。 SQLアンチパターンではアンチパターンの一つとして取り上げられて
複数のテーブルに対して多対一で紐づくテーブルの設計アプローチ｜スパイスファクトリー株式会社
今回は、あまり見かけないようで意外と必要になる「複数のテーブルに対して多対一で紐づくテーブル」の設計について、4つのアプローチをご紹介します。 どのようなケース？あるテーブルが複数のテーブルのいずれかに対して、自身が多、紐付き先が一で関連する場合のテーブル設計です。 例えば、「記事」と「画像」を投稿できるようなSNSを想定します。 この時、閲覧者が投稿された「記事」と「画像」のどちらにも「コメント」をつけることができる機能があったとします。 このような場合に、どのようなテーブルの設計方法があるのか、以下から説明していきます。 1.ポリモーフィック関連SQLアンチパターンにも登場するこの設計方法。「どのテーブルのどのレコード(id)に紐づくのか」という情報をテーブルに持たせてしまうという方法です。具体的には以下のような設計になります。 comments.target_tableに関連する対象
ドメイン駆動設計 失敗したことと成功したこと
その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。 5年という歳月はそれを気づかせるには十分な時間で、 DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。 そのコードは何を失敗していたのか？そして、それは改善するために改善した事とは？ BIGLOBEにおける"今"のいいコードの書き方をできる限り具体的な事例を元に紹介します。
マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング
Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoとGoogle Cloud Platform（GCP）で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい
Clean Architecture で実装するときに知っておきたかったこと - Carpe Diem
概要 developers.cyberagent.co.jp こちらで 課金システムをマイクロサービス化した サービス自体の設計をDDDにした という対応をしました。 当時は試行錯誤の連続でしたが対応から１年程経ち、ある程度設計もfixされてきたので知見をまとめます。 知見 前提 Clean Architectureの図は多くの人が目にしているように以下の通りです。 今回話す内容は青色の部分を除いた ドメイン層：黄色の部分 ユースケース層：赤色の部分 インタフェース層：緑色の部分 です。 ディレクトリ構成 goのリポジトリの構成は以下のようにしています。 . ├── Dockerfile ├── Makefile ├── README.md ├── cmd/ ├── codes/ ├── config/ ├── docker-compose.yml ├── domain/ ├── go.m
JSON-RPCというWebAPI設計に役立ち、、そうなそうでもないかもな規格 - Qiita
背景 内部システム向けにWebAPIを作ろうということになったが、一部のメンバーがRESTに嫌気が指していた。曰く、「（完全な）RESTに則るのは費用対効果に合わない。」 彼の発言を拡大解釈した結果、REST以外の思想に乗っ取りAPIを作りたいのだと思いを汲み取り、名前からしてパット見は全くRESTじゃなさそうなJSON-RPCというデータフォーマットの規格について調べた JSONのデータフォーマット JSONそれそのものの規格はRFC 7159で決まっていますが、それに則りその上でどういった要素にデータを格納していくべきかの設計は各人の好みが別れる所。 例えば、下記で言うとメタ情報はheader、データ部はbodyのリスト、リクエストIDはid、時刻はtimestamp、何かしら問題があればerrorといった、どういう名称の要素に、どういったkey-valueで格納するかなど実運用上、決
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
HTML5 Conference 11/25
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
JavaScript Plugin Architectureというプラグイン設計について学ぶ無料の電子書籍を書いた
JavaScript Plugin ArchitectureというJavaScriptのプラグイン設計についての電子書籍を書きました。 この書籍はJavaScriptのライブラリやツールにおけるプラグインアーキテクチャについて見ていく事を目的としたものです。 以下の形式で読むことができます。 Web版 PDF形式 ePub形式 Mobi形式 GitHub上にソースコードも公開されているでので直接Markdownファイルを読むこともできます。 MarkdownよりはWeb版の方が見やすいのでそちらをオススメします。 Twitterのハッシュタグは#js_plugin_book 更新情報はRSSやリリースノートから見ることができます。 v1.0.0 最初に書くと決めたプラグインアーキテクチャが揃ったので1.0.0としてリリースしました。 JavaScript Promiseの本の時と同じく、継
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計ガイドライン
Clean Architecture in Web Frontend #mixleap - Speaker Deck
GitHub - erikras/ducks-modular-redux: A proposal for bundling reducers, action types and actions when using Redux
複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016