DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
Help us understand the problem. What is going on with this article? 3月24日に発表になったLINEのBOT API Trial Accountが、いよいよ4月7日から実際に試せるようになりました。既に多くのBOTが開発者の手によって作られ始めたようですね。QiitaにもいくつかBOTの作り方が投稿されていますので、"LINE BOT"というキーワードで探してみてください。 実際の作り方の基本は他の投稿に任せるとして、BOT API自体は非常にシンプルな作りなので、試すこと自体はすぐにできると思います。しかし、シンプルな反面、仮に近い将来「Trial」が取れて、友だち50人制限が撤廃された時、それでも正しく安定的に動作するBOTとするには、アーキテクチャ上の工夫が必要になります。個人的に、既にLINE BusinessCo
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
This is #1 in a very long series of posts on Stack Overflow’s architecture. Welcome. Previous post (#0): Stack Overflow: A Technical Deconstruction Next post (#2): Stack Overflow: The Hardware - 2016 Edition To get an idea of what all of this stuff “does,” let me start off with an update on the average day at Stack Overflow. So you can compare to the previous numbers from November 2013, here’s a d
YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括本部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか？ 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性（Eve
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
ITエンジニアのコミュニティサイトStackOverflowなどを運営するStackExchangeが、同社のサービスを支えているシステム構成の状況を知らせるWebサイトを公開しています。 同社のサービスは各国版のStack Overflowのほかにも、サーバ管理者のためのServer Fault、数学関係者のためのMathematicsなど多岐にわたっています。 これらを合わせた同社のサービスは月間5億6000万ページビュー。このページビューを、48GBのメモリを搭載した9台のWebサーバ。384GBのメモリを搭載しライブ／ホットスタンバイ構成にクラスタ化した2台のSQL Serverと、288GBのメモリを搭載した2台のSQL Serverによるもう1つのクラスタの合計4台のSQL Server。96GBのメモリを搭載し、マスター／スレーブ構成にした2台のRedis Serverなどで
はじめに このエントリは GREE Advent Calendar 2014 24日目の記事です。 こんにちは、インフラストラクチャ本部の高野(@takano32)です。 いつも社内では GitHub:Enterprise の運用、 デプロイの改善、 大規模なインフラを操作するためのツール作成、 レガシーなサーバのセキュリティ対策、 コミュニケーションツール向けシステムの構築・運用、 などの仕事をしています。節操がありませんね。はい。 そのうち、今回は「コミュニケーションツール向けシステムの構築・運用」のうち「グリーを支える通知システム」という題目について書きたいと思います。 グリーとリアルタイムコミュニケーションツール まず、通知システムについてお話する前に、グリーでどのようなリアルタイムコミュニケーションツールが利用されてきたかを簡単に説明したいと思います。 リアルタイムコミュニケーシ
モノリシックがダメだからといって、マイクロサービスが解決策になるわけではない ソフトウェア開発業界は流行に左右されやすいという証拠に、今マイクロサービスが、いたるところで大騒ぎされています。”次の大ブーム”だと思う人もいるでしょう。また、（10年前に”上出来”と見なされたような）大型のSOA、サービス指向アーキテクチャが単に軽量化して進化したものだと捉える人もいるでしょう。私は現在のマイクロサービスアーキテクチャに関しては好意的に見ています。しかし、だからといってこのアーキテクチャは決して万能薬ではありません。言うまでもないことかもしれませんが、多くの人が間違った理由でマイクロサービスに飛び付いているように思えるのです。 これは私の講演でよくお見せするスライドで、 以前ブログにも書きましたた が、ソフトウェアシステムを開発するにはいろいろな方法があります。まず、昔ながらのモノリシック（一枚
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of two or more services that are: Independently deployable Loosely coupled Services are typically organized around business capabilities. Each service is often owned by a single, small team. For a business to thrive in today’s volatile, uncertain, complex and ambig
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
