サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事は一休.com Advent Calendar 2025の13日目の記事です。 宿泊開発チームでエンジニアをしている @kosuke1012 です。本記事では、予約処理の中で必要な在庫引当、カード決済などの各処理について、予約処理全体として成功/失敗の結果整合を実現するための実装パターンを紹介します。 背景 現在、一休.com の宿泊予約のシステムでは、予約部分のリニューアルを進めています。 予約リニューアルプロジェクトの全体感もどこかで是非説明したいのですが、アドベントカレンダーの期日も迫ってきているため、 リニューアルの中で取り組んだ、予約処理の結果整合を実現するための実装について書いてみたいと思います。 用語 この記事内での用語の定義をしておきます。 この記事の中で「トランザクション」と言った際には、予約処理全体を指すことにしたいと思います。 また、「カード決済」「在庫引当
ソフトウェア開発の現場が日々感じている問題は、しばしば組織設計の不備を映し出す鏡である。 そうであるなら、現場で営まれる改善に向けた努力は “対症療法” にしかなり得ない。一時的に症状を緩和できても、しばらくすれば問題はぶり返す。現場はそれを再び抑えにかかる。これではまるで、終わりのないモグラたたきだ。 組織設計の改善による “原因療法” が必要なのだ。もちろん対症療法も必要ではある。しかし、根本原因を取り除かなければ、そこから生じる問題が現場を苦しめ、ソフトウェア開発の足かせであり続ける。それはビジネスの足かせでもある。 だから、組織設計に携わるマネージャーには、現場に現れる症状から組織設計上の問題を読み解く力が問われる。そして、現場のチームも巻き込んで、組織の欠陥修正や、組織のリファクタリング、リアーキテクティングに取り組むのだ。 参考資料 組織設計のひずみは現場に問題をもたらす 例1
ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削
「情報設計（IA: Information Architecture）」は、ユーザーが目的の情報に迷わずたどり着くための基盤となる重要な考え方です。私は国内向けのサービスを運営している事業会社に所属しており、普段からいろんなサービスを触っているうちに、日本と欧米のサービスの情報設計に大きな違いがあることに気づきました。 この記事では、日本と海外における情報設計の思想の違いについて調べたことを紹介します。 情報量満載の日本、削ぎ落とす欧米たとえば、楽天市場の日本版は、文字・画像・リンクが密集し、ファーストビューだけで何十もの情報が目に入ります。一方、Rakuten USは白を基調とした余白のあるレイアウトで、ユーザーの視線を絞り込むように設計されています。 同じ傾向はスターバックスにも見られます。日本版はキャンペーンや新商品を賑やかにアピールし、画像も豊富。一方、アメリカ版は大きなビジュアル
【PR】 2025.01.10ITニュース 注目企業 データセンターも、クラウドも、ECサイトも……わざわざ自前で用意する必要のないこの時代に、圧倒的自前主義を貫く企業がある。国内売上2位のECサイト『ヨドバシ・ドット・コム』でもお馴染みの、ヨドバシカメラを展開するヨドバシグループだ。 膨大な時間とお金がかかる道をなぜあえて選ぶのか。その理由を、グループ全体のサービスをITで支えるヨドバシリテイルデザインの事業部長・戸田宏司さんは「目先の利益よりも10年後、20年後も愛されるサービスづくりが重要なんです」と語る。 国内家電量販店の中でも売上2位を誇る同グループだが、「10年後、20年後も愛されるサービスづくり」とは一体どういうことなのか。戸田さんに話を聞いた。 ヨドバシリテイルデザイン 事業部長 戸田宏司さん 1982年、小学生時代からプログラミングを開始。1998年、フリーランスとして
『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が
しのゆー𝕏今や酒ザコエンジニア @shinoyu 法人やってるソフトウェアエンジニア20年生+見習いバーテンダー 兼蒲田のガルバのオネェさん/IT、V系 、ロリィタの人 / 鍵アカからのフォローは教義によりブロック mixi.social/invitations/@s… しのゆー𝕏酒クズエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書いらないわけで… 2024-05-31 0
GraphQL is an incredible piece oftechnology that has captured a lot of mindshare since I first started slingingit in production in 2018. You won’t have to look far back on this (rather inactive)blog to see I have previously championed thistechnology. Afterbuilding many aReact SPA ontop of a hodge podge of untyped JSON RESTAPIs, I foundGraphQL a breath of freshair. I was truly aGraphQL h
ヨドバシカメラは現在、お客様との接点をドメインとして設計する新たなAPIを開発中であることを、クリエーションラインが主催し10月27日に開催されたイベント「Actionable Insights Day2023」で明らかにしました。 RESTAPIとして実装される予定のこのAPIについて同社は「ヨドバシスタッフの魂を注入する」としており、厳重なセキュリティやユーザーフレンドリーで高い利便性などが追求されています。 ヨドバシAPIがどのように設計され、開発、実装されていくのか。その中味が紹介されたセッションの内容を見ていきましょう。本記事は前編と後編の2本の記事で構成されています。いまお読みの記事は前編です。 疎結合なのに一体感、ヨドバシAPIがつなぐ社会 株式会社ヨドバシカメラ 代表取締役社長 藤沢和則氏。ヨドバシカメラの藤沢と申します。本日はまずこの貴重な機会をいただきありがとう
こんにちは。バクラク事業部 Enabling チームの @izumin5210 です。最近「HUNTER×HUNTER」の既刊を全部読みました。 この記事はLayerXテックアドカレ2023の9日目の記事です。 前回「1人目データアナリストとしてデータチームに異動しました 」 次回「Slack × Zapier ×MiroでKPTでの振り返りをラクにする」RDB や KVS などのデータ保存先において、データを正規化せずにそのまま保存したいと思うことはありませんか？ 8月にリリースされた「バクラク請求書発行」というプロダクトには「柔軟なレイアウトカスタマイズ」機能が搭載されています。リンク先の画面操作イメージを見ていただくと、この機能の雰囲気を理解していただけると思います。この機能が扱うレイアウトデータはまさに「関係の正規化をせずに保存したいデータ」でした。 bakuraku.jp こ
アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由 日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
巷で、顧客の課題を解決しつつ、より良いシステムを作るための設計手法として、ドメイン駆動設計（DDD）が話題になっていると思います。 このドメイン駆動設計について、どのように実践するか、実際に実践してみてどう感じたか、という話はよく出ていますが、作られたシステムがその後どのようになったのか、保守開発した結果どう感じたのかの話はあまり聞かないな、と思ったので、自分の経験から「実際のところどうなんだ」というところを振り返ってみようかな、と思い、今回の記事を書きました。 目次 私が保守開発しているシステム 5ヶ月の間にやったこと 保守開発していて感じたこと よかったこと 改修時に修正箇所が特定しやすかった テストコードが書きやすく安心して保守することができた 成長できたという実感があった 難しかったこと、学び ドメイン知識は次第に流出していく 定期的なメンテナンスが大事 最後に おまけエンジニア
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
初めに きっかけ 新人研修中にDDDとか、PoEAAとかの話が少しだけ出ました。 ただ、イマイチわからないとの声が多数。 理由 なぜなら予備知識がたくさん必要だからです。(ほんとに多い) これはわからなくて当然。 そこで 独断と偏見で、予備知識となる用語を解説します。 偏見多いので、より正確な情報は、書籍やWebで調べてね。 この辺を説明します UML クラス図/シーケンス図 デザインパータンGoF/PoEAA 階層化アーキテクチャ DDD本のサマリ 知らなきゃいけない知識が多くて面倒だね。 説明しないけど、オブジェクト指向やデータベースとかの知識も必要だよ。 説明前にDDD本のページを見てみよう！！！ DDD本の最初のページ 「エリック・エヴァンスのドメイン駆動設計」より ??? よくわからないね さっきの図って何? 灰色の中心部分はソフトウェア設計のモデリングを表しています。 モデリ
はじめにAWS上で仮想ネットワークを構築できるAmazonVPCは、多くのAWSサービスが動作する基盤となる、非常に重要かつ多機能なサービスです。 多機能ゆえに公式ドキュメントやネット上の記事も断片的な機能の解説が多く、全体像を把握することが難しいサービスとも言えます。 そこで本記事はVPCの全体像を理解できるよう、各機能のつながりや動作原理を丁寧に解説し、 「VPC界の百科事典」 (あくまで例えですが…笑) となるような記事を目指したいと思います。 【追記】 実践編の記事を追加しましたVPCの実画面での構築方法は、以下の別記事にまとめました。「VPCを実際に触ってみたい！」という方は、こちらもご一読いただけると嬉しいです。VPCとは 「Virtual Private Cloud」の略で、クラウド上に仮想的なネットワークを構築するためのサービスです。 例えば、オンプレ環境でWebア
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
なぜ僕が「SPAはコストが高い」と考えているのか を読みました。 「反論お待ちしています」とのことなので、書いてみます。 結論としては、 コストが低いのは慣れているほうだよ。 どっちも使えるならSPAのほうが低いよ。 です。 前提 元記事で挙げられている前提をまとめます。 用語 SPAとは、クライアント側でビューを構築する方式を指す MPAとは、サーバ側でビューを構築する方式を指す 背景エンジニアのスキルはあまり高くない 開発期間は1.5年未満PMFを意識したフェーズであり、チャレンジを繰り返す ログイン機能が存在するサービスを作る コストの定義エンジニアの採用のしやすさ サービス開発の 初速 サービス開発の 継続性 分業のしやすさ、手伝ってもらいやすさ web標準の挙動の実現のしやすさ セキュアなデータを流出する可能性の高低 バグがあった時の気づきやすさ / 対応のしやすさ ドキュ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
