Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的と
Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか
600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw …
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
「アーキテクチャ」に対する一般的なイメージ インフラ設計図のような青写真──機能やデータがどこに配置され、どう結び付くかを俯瞰で示す全体像。 システムの骨格とルール──技術スタックやモジュール分割、データフローなど「こう作るべき」を規定する枠組み。 将来への建築基準──性能・安全性・保守性を支え、変更や拡張の自由度を左右する長期的な基盤。 「アーキテクチャ」の本質的な意味 建築から哲学、テクノロジーまで幅広い分野で使われ、人間の行動様式や社会関係を規定する重要な要素となっている。 建築物が人の動きを決めるように、社会制度やテクノロジーのアーキテクチャも私たちの行動や権力関係に影響を与えている。 ローレンス・レッシグのアーキテクチャ アーキテクチャは、人々の行動を規制する4つの力(法、社会規範、市場、アーキテクチャ)の1つとして定義される 「ある選択肢を選びやすく/選びにくくする」 という性
「データ指向アプリケーションデザイン」をベースに、24時間365日動き続けるデータシステムを実装する際に必要となる技術や考え方を紹介します。 この資料は、2023年大阪大学大学院 情報科学科 マルテメディア工学特別講義で使われた資料を一般用に修正して公開しています。 参考： 「30分でわか…
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに バッチ処理とは、大量のデータを一括で処理するための手法であ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する
ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考え…
全てのAPIをProtocol Buffersで管理する / Manage all APIs with Protocol Buffers
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに 昨今のWebフロントエンド領域は、単なるHTML、CSS、
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
設計の「why」を言語化できる人は強いんですよ— magnoliak🍧 (@magnolia_k_) 2022年10月29日 っていうか、驚くくらい「why」が上手く表現できないんですよ、普通は 手順は言えても、なぜ？が言えない— magnoliak🍧 (@magnolia_k_) 2022年10月29日 設計において、すべての決定について仔細に「なぜ、そうしたか？」を言えるべきなのだけど、これを上手く言語化できない人は多い。「このプロジェクトでは以前からそうしているから」「そうするのが当たり前だと思っていた」などなど、本当に理解してないまま「設計という作業」を進めている人もいれば、上手く自分の行為を言語化できないだけの人もいる。 また、必ずしも自分が設計したことについて説明する場面ばかりとも限らない。既に存在する設計から「なぜ」を類推するしかない場面もある。他人のコードを読み取るとき
ソフトウェアエンジニアの 鈴木 (@szk3) です。 先日、カミナシにおいて古くから存在する１つの機能をリアーキテクティングしました。 その結果、処理時間は4分の1以下、コストは90%程度削減 と大きな成果を出すことができました👏 本記事では、その機能が抱えていた課題に対しどのような改善のアプローチをして上記の結果に結びついたのか？について共有します。 Excel変換とは 今回、リアーキテクティングの対象となった機能は、カミナシに帳票として記録されたデータをExcel形式に変換して出力する機能です。 これを、”Excel変換” と呼んでいます。 Excel変換は、カミナシのサービスの中でも比較的古くから存在する機能です。 ここ数年での利用ユーザーの増加と共に、設計当初のシステムアーキテクチャが技術的な負債となっている状態でした。 Excel変換の課題 まず最初に、設計当初のアーキテクチ
23新卒技術研修で実施したテスト・設計研修の講義資料です。 動画：https://youtu.be/xR-LWJ4MAEM 資料の利用について 公開している資料は勉強会や企業の研修などで自由にご利用頂いて大丈夫ですが、以下の形での利用だけご遠慮ください。 …
Facilo（ファシロ）は、不動産仲介という業務フローが極めて複雑な領域で、あえて「構成・組織・開発プロセス」をできるだけシンプルに保つ方針を選んできました。 シングルデータベース、削除フラグなし。さらに、Devinを標準ツールとする全社的なAI活用まで。 なぜそこまでシンプルさにこだわるのか。その判断は、マルチプロダクト展開という事業戦略や組織づくり、AI時代のエンジニアの価値とどうつながっているのか——。 今回は、同社CEOの市川紘さんとCTOの梅林泰孝さんに、Faciloのプロダクトの現状と技術・組織に通底する設計思想を伺いました。 ※ この記事は株式会社Faciloによるタイアップ広告です。 一点突破から「マルチプロダクト戦略」に振り切った理由 マルチプロダクトになっても開発スピードが落ちないように準備してきた データベースは一つ、「外部キー」や「削除フラグ」は設けていない ベスト
こんにちは。 この記事では、2024/5/22に開催された「アーキテクチャを突き詰める Online Conference」で弊社CTOの普川がお話しした内容（ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する〜モノタロウ基幹システム刷新の実践例）を、現場目線から改めてご紹介します。 なお、本稿の執筆は頼と尾髙が分担しておりまして、途中で急に文体が変わったな？と違和感を持たれることもあろうかと思われますが、ご容赦いただけますと幸いです。 本稿をさらに深掘りするイベントを10/4(金)に開催いたします。 ご興味ある方はぜひご登録ください。 https://connpass.com/event/328360/ 問題領域は関連システムの密結合点 分割を試みる 最初のモデルを手に入れる レイヤードアーキテクチャに沿って実装 レイヤードアーキテクチャのメリット モデルを洗練させ
最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。 単なる感想です。 pospomeのマイクロサービス歴 面倒なのは技術ではない モノリスだと厳しい 楽しくもある 宣伝 pospomeのマイクロサービス歴 以下の企業で7年ほどマイクロサービスに携わっている。 DeNA（ゲームプラットフォーム） メルカリ（認証認可基盤） DMM（DMMプラットフォーム） DeNA, メルカリではサーバサイドエンジニアとして仕事をしていて、 DMMではプラットフォーム事業本部という120人のエンジニアが在籍する開発組織のアーキテクトとして仕事をしている。 それぞれの会社で開発の規模感、開発体制、自分の役割などが異なるので、 直接比較できないが、やはりポジション的に今のDMMが一番大変だなーと感じる。 面倒なのは技術ではない マイクロサービスというと "分散トランザクション" とか "通信
2023/02/10、デブサミ2023の登壇資料です。 『目的と抽象化の関係性から分かる、システムの設計精度を高める考え方』 https://event.shoeisha.jp/devsumi/20230209/session/4182/
ソフトウェアの中身を大きく2つに分解すると、プログラムとデータに分かれます。コードコンプリートやA Philosophy of Software Designなど、評判の良いソフトウェア設計の本はいくつかありますが、それらはどれもプログラムの説明がメインでデータのライフサイクルについての説明はなかったと思います。しかし、データの表現にもいくつもの方針があって、それによるトレードオフがあるな、というのはもやもやと考えていたので、その考えをまとめて文章にしてみました。 データといっても、処理中の短期間の間では変わらない、いわゆるマスタデータ的なデータです。ジャーナルというか、トランザクション的なデータはここでは触れません。 この記事では、それぞれのトレードオフについて考えていきます。 即値（リテラル） 定数 コマンドライン引数 環境変数 設定ファイル ダウンロードコンテンツ オンラインデータベ
Qiita Conference 2025 における発表の資料です。 設計とはなんだろうか、というお話をしています # プロポーザル https://qiita.com/official-campaigns/conference/2025#day1 設計とは単なる技術的な構造を定める行為…
設計原則、アーキテクチャパターン、アーキテクチャスタイルの違いって何？いつどう向き合ったらいいの？を考えてみる
こんにちは。AI ShiftでWebフロントエンドエンジニア（？）をしている安井です。今回は私がAIエージェント開発において模索した、組織の強みを最大限に活かすためのアーキテクチャ設計を紹介します。 AI ShiftではAI Workerという企業専用のAIエージェント構築プラットフォームを開発しており、我々開発メンバーは自然言語処理を強みとするチーム（以下AIチーム）と協働してプロダクト開発をしています。 感じていた課題 ＊これは私個人が感じていた課題感であり、組織全体の考えでないことを強調します。 AI Shiftでは5年以上前からAIをドメイン領域として、チャットボット、ボイスボットなどの開発をしてきました。当時はAIチームの研究力がプロダクトの強みとしてダイレクトに反映されており、開発チームとしても如何にその研究力をプロダクトに活かすかが重要な視点でした。 しかし、2024年頃から
はじめに こんにちは。基幹システム本部・物流開発部の岡本です。普段はZOZO基幹システムのリプレイスを担当しています。 ZOZOではさらなる成長のため、様々なリプレイスプロジェクトが進行しており、これまでにZOZOTOWNやWEARなどのプロダクトにおける多くのリプレイス事例を公開してきました。本記事では、2022年8月より本格始動したZOZO基幹システムリプレイスの第一弾であるZOZOの物流拠点「ZOZOBASE」を支える「発送システムリプレイス」を紹介します。「発送システムリプレイス」は設計を終えた開発段階で、リリースに向けて進行中です。本記事を皮切りに今後も継続的に発信を続けていくので、是非ご注目ください。 現状の「発送システム」は、Classic ASPのトランザクションスクリプトで実装された大規模なモノリス構成のシステムの一部であり、「障害リスク」と「開発速度の低下」に課題を抱え
OpenTelemetry Meetup の登壇スライドです。 https://opentelemetry.connpass.com/event/296353/
シリーズ: 要件定義とはそもそも何か 要件定義の目的とゴールとは 要件定義の重要ポイント〜要望・要求・要件を見極める 事業・業務・システムの3階層で要件を捉える 業務フロー図で見える化する業務プロセスからシステム要件への道筋 ユースケースとロバストネス図によるシステム要件定義 システム要件定義の成果物〜設計へのインプットを作成する 要件定義とソフトウェアアーキテクチャ設計（本記事） 要件定義とクラス設計 要件定義とデータベース設計 要件定義と画面設計 要件定義とAPI設計 要件定義とバッチ処理設計 要件とは何か 非機能要件とは何か 要件定義を学ぶ人におすすめの書籍まとめ 移行要件とは何か 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】 要件定義と設計の関係を体系的に理解する【全体像まとめ】 TRACERYプロダクトマネージャーの haru です。 設計プロセスでは、要件定義で
freeeにおけるモジュラモノリスの事例を大規模プロダクトから新規プロダクトまで紹介します。
ログラスの龍島(@hryushm)です。最近は秋に備えて干し芋を作る練習をする日々を過ごしています。 ログラスではオニオンアーキテクチャを採用してしてDDDを実践しています。直近プロダクトのスケールによってデータのレポーティング、集計処理のパフォーマンス劣化の問題が顕在化、早急な対応を迫られる事態となっていました。その対応としてRDBMS(PostgreSQL)からDWH(BigQuery)へ一部のクエリを移行しました。オニオンアーキテクチャの恩恵で移行が比較的容易であり、実装自体は1ヶ月というスピードで終えることで顧客に素早く価値提供できたため、実例として記事にしたいと思います。 オニオンアーキテクチャと利点 オニオンアーキテクチャ自体の説明は多数の記事があるため省きますが、弊社松岡の記事が理解しやすいと思います。 記事中にあるレイヤードアーキテクチャと比較した時に肝となる、依存性逆転の
バックエンドエンジニア taisa です。最近腸活によって少しだけ体重が減りました。テックタッチは最近クリーンアーキテクチャにおけるユースケース層の大規模なリニューアルを行いました。本記事では、リニューアルの際に工夫した内容を簡単に紹介します。 はじめに 前提条件 1. ユニットテスト・インテグレーションテストを用いた差分検証 ユニットテストの拡充 インテグレーションテストの拡充 2. 同時実行パターンによる差分検証 同時実行パターンとは AWS AppConfig とは 3. 動的な切り替え機能を利用した段階的な移行 まとめ はじめに テックタッチのバックエンドはクリーンアーキテクチャとドメイン駆動設計（DDD）を組み合わせた構成で開発を進めています。詳細な理由や背景は割愛しますが、開発生産性の向上を目的に、クリーンアーキテクチャにおけるユースケース層のリニューアルを実施しました。その際
こんにちは、ヘンリーの Lead Architect の @kohii です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 最近 Henry のバックエンドをモノレポ化したので、その戦略やプロセスについて書きたいと思います。 こちらは前編となっており、モノレポ移行の手法やテクニックの話は後編で説明します。 dev.henry.jp Why モノレポ？ ざっくり説明すると、既存のマイクロサービス/チームの分界点を抜本的に見直し、ドメイン（業務の領域）による分割を目指すため、一旦モノレポにまとめて、理想的な構造の切り出しをやりやすくするという目的です。 モノレポ化前のシステム/チームアーキテクチャ バックエンド Henryのバックエンドはマイクロサービスになっていますが、以下の2つのサービスが大部分を占めています。 henry-general-api …
Kaigi on Rails 2025で話した "Railsによる人工的「設計」入門" の資料です。
Monorepoとは？ Monorepo(モノレポ)とは、アプリケーションやマイクロサービスの全コードを単一のモノリシックなリポジトリ (普通は Git) に保存するパターンを指します。 一般的には、さまざまなアプリ コンポーネントのコードをサブフォルダーに分割し、新機能やバグ修正には Git ワークフローを使用します。 モノリシック アーキテクチャでアプリケーションやシステムを開発するのであれば、たいていは、こうしたアプローチを自然と採用することになります。 通常、このようなMonorepoでは、コードから実行可能なアプリケーションを生成するビルド パイプラインも 1 つだけです。この手法は、メンテナンスはしやすいのですが、全体的な開発速度は落ちます。修正に手間のかかるバグが少しあるだけで、リリース候補版を本番環境にデプロイできなくなってしまうからです。 この記事では、Monorepoと
こんにちは! ソウゾウのSoftware Engineerの@ogataka50です。連載：メルカリShops 開発の裏側 Vol.2の9日目を担当させていただきます。 9日目はメルカリShopsを開発する中でのDesign Docsの運用について紹介させて頂きます。 Design Docsとは Design DocsとはGoogleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的になります。 例として、GoogleでのDesign Docsについては下記にまとめられています。 Design Docs at Google メルカリShopsでのDesign Docsのte
2023年4月11日に開催されたクラスメソッド株式会社のイベント、DevelopersIO DayOne で発表したスライドです。 「モノリスかマイクロサービスか、その選択に迷っている人へ届けたい話」をマイクロサービス導入ステップやチーム作りの観点から解説しました。
13-B-1 Architecture to Design より良い設計を目指して Feb. 13, 2025 Takeshi Yonekubo About Me 米久保 剛 (よねくぼ たけし) 株式会社電通総研 ITアーキテクト 『アーキテクトの教科書』（翔泳社） X: @tyonekubo note: https://note.com/yonekubo 12:30〜 3F 休憩ラウンジ 翔泳社書籍販売コーナー にてサイン会実施！
ここ数年、「シフトレフト」という言葉を耳にする機会が増えました。 テスト、QA、セキュリティ、運用―― 何かにつけて「シフトレフトしよう」という言葉が使われます。 一方で、正直なところずっと違和感もありました。 話を聞いていると、人によって指しているものが違います。 テストを早く書くことを指す人もいれば、 QAを設計段階から巻き込むことだと言う人もいる。 レビュー工程を前倒しすることだ、という説明を聞いたこともあります。 どれも間違ってはいないと思うのですが、どれもしっくりこなかったです。 なぜなら自分自身は、 ウォーターフォールでもアジャイルでも、 シフトレフトという言葉を意識せずに、同じようなことをずっとやってきたからだと気づきました。 しかも、そのやり方で 「大きく炎上した」「後工程で破綻した」 という経験はほとんどありませんでした。 最近になって気づいたのは、 自分が自然にやってい
Now available: Orchestrate Claude Code, Codex, and Warp Agent in Oz Learn More
設計原則と 普遍的な判断軸 Takeshi Yonekubo Oct. 29, 2025 AI×設計入門 〜設計原則とドメイン駆動開発 で見つける次のステップ〜 About Me 米久保 剛 (よねくぼ たけし) ITアーキテクトとして自社プロダクト 開発業務をリード 最近は組織のアーキテクティングに興味 『アーキテクトの教科書』（翔泳社） X: @tyonekubo note: https://note.com/yonekubo
これは エムスリー Advent Calendar 2022 の27日目の記事です。 前日は id:yusukemoon による、エムスリー × マネーフォワード『社会を変えるサービスデザイン』振り返りと感想でした。 エムスリーエンジニアリンググループ AI・機械学習チームの笹川です。 趣味はバスケと筋トレで、このところは、年末の休暇に作ろうとしているOSSのことを考えています（大体いつも考えるだけで終わらないことが多いので今年こそは）。 今回は、巨大なモノリスアプリケーションをマイクロサービスに分割するという「できたらかっこいいけど、まぁまぁ厄介なタスク」に対するアプローチの一案を紹介します。 この取り組みはまだ弊社のアプリケーションの分割には使われておらず、考えてみたという段階ですが、あまり見ない方法かなと思ったので、少しでも参考になる所があればと思っています。 プロ並みの布団捌きで上
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
