いいねとその通知機能をDynamoDBで設計したら思ったよりムズい - エムスリーテックブログ
【Unit4 ブログリレー4日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、SNSではごく一般的ないいねとその通知機能をDynamoDBを利用して実装したら思ったより大変だったので、その詳細をご紹介します。 キャナルシティ劇場は、福岡県福岡市博多区の複合商業施設「キャナルシティ博多」のシアタービル最上階に位置する劇場。本文には特に関係ありません。 m3ラウンジ m3ラウンジのいいねとその通知の要件 RDBで実装したらどうなるか いいね機能 通知機能 DynamoDBで実装する いいね機能 通知機能 いいねする いいねを取り消す 通知を表示する 未読の通知の取得 未読の通知数 未読の通知を既読にする テーブル設計むずい PKとSKに何を選ぶか LSIは途中から作れない DynamoDBをローカルで動かして設計する まとめ We are h
初めてDDDを使ってみて悩んだところ
研修でDDDを使ったサービスを作ってみることになったが、DDDを使うのが初めてなので同じような状況の人向けに悩んだところをメモしておこうと思う。 DDDとは DDD（Domain-Driven Design）とはドメイン駆動設計と呼ばれる設計方法の一種で、複雑なビジネスの要件をソフトウェアで上手く扱うためのアプローチとなっている。（DDDの詳しい説明などは以下を参照） DDDはドメイン（業界領域）の複雑さにフォーカスを当て、ドメインに精通しているドメインエキスパートと呼ぶ人の協力を得てシステム開発を行ってい行く。また、DDDではクリーンアーキテクチャ、ヘキサゴナルアーキテクチャなどのアーキテクチャと共に用いられることが多い。（今回作っているサービスではクリーンアーキテクチャを採用しているつもりだが、他のアーキテクチャとの違いが正直良く分かっていない） サービスの概要 ざっくりと説明すると、
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
クックパッドマートの失敗したデータ設計 Before / After 大放出
https://cookpad.connpass.com/event/249346/ にて発表。
簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々
ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ
本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では？」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは？」とアジャイル開発に興味が移りました。 本記事では、ドメイン
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
Clean Coder Blog
I want to become a Software Architect. That’s a fine goal for a young software developer. I want to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff. Oh. Well, then you don’t want to become a Software Architect after all. Of course I do! I want to be the one who makes all the important decisions. That’s fine, but you didn’t list the
DDDを実践するための手引き（概論・導入編）
ナニコレ DDDは「Domain-Driven Design（ドメイン駆動設計）」の略語で、エリック・エヴァンスさんという人が考えるソフトウェア設計におけるプラクティスまとめみたいなものです。 『エリック・エヴァンスのドメイン駆動設計』というバイブル的な書籍がありますが、「途中で挫折した」「読んでもよくわからない」「よくわからないけど自分なりに解釈して実践している」というような感想をよく聞きます[1]。DDDの概念は幅広く、哲学的で、抽象的であるため、DDDをどのように解釈しどのように実践すればいいのかわかりにくいものです。 この記事ではそのような問題に悩んでいる人たちのために、数年に渡りDDD（的なもの）を実践してきた筆者が噛み砕いた（個人の独断的な）解釈と実践方法を解説します。 DDDってなぁに？ DDDがカバーする領域 DDDが言及する範囲はとても幅広いです。エリック・エヴァンスさん
AWSにおけるALB&NLBのBlue/Greenデプロイメント設計 - How elegant the tech world is...!
はじめに どうも、iselegant です。 前回、執筆した商業誌について本ブログで紹介させていただいたところ、大変多くの反響がありました。 コメントをくれた方、書籍に関心を持っていただいた方、本当にありがとうございます🙇 AWSコンテナ設計・構築[本格]入門 | 株式会社野村総合研究所, 新井雅也, 馬勝淳史, NRIネットコム株式会社, 佐々木拓郎 |本 | 通販 | Amazon 本日から少しの間、分量調整と締め切りの都合上、商業誌では執筆しきれなかった AWS 設計に関するサイドトピックについて、本ブログ上でご紹介したいと思います。 今日はALB (Application Load Balancer) と NLB (Network Load Balancer) の Blue/Green デプロイメントに関する設計がテーマです。 AWS で Web アプリケーションの可用性とパフォ
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
フロントエンドアプリケーションにおいて状態をどこに置くべきか論 - Runner in the High
後学のために自分の考えていることをまとめてみる。 考えられるパターン これまでの経験から以下4つのパターンがある。 ローカルStateでprop-drillingする ローカルStateかつイベント経由でデータ交換をする グローバルStoreとローカルStateを併用する グローバルStoreのみを使用する 1. ローカルStateでprop-drillingする propとしてコンポーネント間のデータをやりとりする手法。 ほぼすべてのUIコンポーネントを親からデータを受け取りDOMを出力するだけの純粋な関数として表現できるため、全体の設計自体はシンプルになる。手間は多いが魔法は少ない。 コンポーネントの粒度が小さいアプリケーションの場合にはいわゆるバケツリレーと揶揄されるデータの受け渡しが頻発し、これに嫌悪感を持つエンジニアもいる。 2. ローカルStateかつイベント経由でデータ交換を
Goの構造体の使われ方の設計 | フューチャー技術ブログ
Goで構造体を設計する場合、オブジェクト指向的な「型ごとの責務の分担」以外に、「どのように使われるものか」を考える必要があります。 ポインタで扱うのか？値として扱うのか？両方許可するのか？ 値として扱える場合にimmutable（変更不可能）なオブジェクトとするのか、mutable（変更可能）なオブジェクトとするのか 値として扱える場合にゼロ値での動作を補償するかどうか 他の言語で言うと、C#の構造体とクラスの違い、C++のデフォルトコンストラクタあたりに頭を悩ませたことがある人にはおなじみかもしれませんが、Goでもいくつか考慮が必要になります。 ポインタ型として扱う必要があるケースまず最初に決断できる方針としては、ポインタ型でのみ扱うかどうかです。 内部にスライスやmap、ポインタなどの参照型な要素を持っていれば、基本的にポインタ型でのみ扱う構造体になります。これらの要素を持っていた場合
RDBMSの苦手なことを 如何に乗り越えていくか / challenge-to-rdbms
# 参考資料 - イミュータブルデータモデル(入門編) - https://www.slideshare.net/kawasima/ss-40471672 - イミュータブルデータモデル(世代編) - https://www.slideshare.net/kawasima/ss-44958468 - スタースキーマ（基礎） - https://zenn.dev/pei0804/articles/star-schema-design - ディメンション・モデリング - https://zenn.dev/pei0804/articles/dimensional-modeling - 失敗から学ぶRDBの正しい歩き方 - https://amzn.to/3vfD5nJ
仕様整理のためのテスト設計入門をJaSST'21 Tokyoで発表しました | BLOG - DeNA Engineering
はじめに 品質管理部の河野です。先日、 ソフトウェアテストシンポジウム 2021 東京 の企画セッションで「仕様整理のためのテスト設計入門」というタイトルで発表してきましたので、本ブログでは発表に至った経緯や発表の感想などを報告いたします。 発表の経緯 まず、タイトルを見た方は、仕様を整理するためにテスト設計を使うのか？ と考えられたと思いますが、その通りでテスト設計はテストケースを設計する行為なのですが、実はテストケースを設計する過程で仕様を整理していることが多いです。ということで、テスト設計のための技術である、テスト設計技法を理解しながら、演習を交えて仕様の整理を実感できるような構成でチュートリアル形式で90分の発表を行いました。 それで、このようなテーマを思いついたきっかけは、私が以前作成したテスト設計の入門のテキストを近くの開発者の方に「開発者向けにやったら需要ありますか？」と質問
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
テスト・設計研修【MIXI 23新卒技術研修】
ふつうのプログラマのふつうの設計
IBM Dojo 挫折しないドメイン駆動設計 20210825pm
