On-The-Blockサービス開発記 01

2026年度1学期にCapstone Design科目を履修しながら、チームプロジェクトとしてOn-The-Blockというサービスを開発することになりました。

まず、このサービスはカクテル、バー、リカーショップに関する情報、コミュニティ、推薦システム、チャットなど、「Danggeun Market + Dailyshot」の機能を組み合わせた形のサービスを提供しようとしています。

On-The-Blockという名前は、バーでお酒を飲むときに使うOn the rocksという表現を参考にして作った名前です。個人的には口に馴染んで良いと思っています。

3人で進めるプロジェクトで、MSA(Micro Service Architecture)形式で開発する予定です。MSAで進める理由は、各自の主力言語が違い、目標も違うため、それぞれが最も得意な言語と技術で開発するのが良いと判断したからです。また、テーマが少しありきたりではないかと思うかもしれませんが、就職するならこういうサービスも当然必要だと思ったため、このサービスを開発することにしました。

実装する機能

表で整理するのがきれいだと思ったので、文書に書いた表をそのまま載せます。

機能分類	詳細機能	核心技術 (Tech Stack)	担当
認証およびコマース	会員登録、成人認証、酒類スマートオーダー、決済パイプライン、地域認証	Java/Kotlin, Spring Boot, Spring Security, PostgreSQL, Redis	Java
リアルタイム相互作用	飲み会/集まり、グループチャット、リアルタイム参加通知	Go/Rust, gRPC, WebSocket, Amazon DynamoDB	Go/Rust/C++/C
知能型サービス	アンケートベースの酒類推薦、異常取引検知(FDS)、推薦モデルサービング、チャットボット	Python, Qdrant, Airflow, ONNX Runtime	Python/C++
位置および検索	地図ベース周辺バー探索、ハイブリッド検索、公共データ(POI)	OpenSearch, PostGIS, 公共データ	共通
データパイプライン	サービス間イベント中継、ユーザー行動ログ収集、CDCデータ同期	Apache Kafka, Amazon MSK, AWS Lambda, DynamoDB Streams	共通
Admin	店舗在庫管理、注文状況ダッシュボード、ユーザーマナー温度管理	Java/Kotlin, React/Vue	Java, JavaScript
インフラ/DevOps	コンテナオーケストレーション、IaC、CI/CD自動化	Kubernetes (EKS), Docker, Terraform, Helm, GitLab CI	共通

担当役割

機能分類	詳細機能	核心技術 (Tech Stack)	担当
リアルタイム相互作用	飲み会/集まりマッチング、グループチャット、リアルタイム参加通知	Go/Rust, gRPC, WebSocket, Amazon DynamoDB	Go/Rust/C++/C
知能型サービス	アンケートベースの酒類推薦、異常取引検知(FDS)、推薦モデルサービング	Python, Qdrant, Airflow, ONNX Runtime	Python/C++

共通と書かれている部分は、チームメンバーと一緒に勉強しながら開発することにしました。私はチャットシステムと推薦システムを担当して開発することにしました。

イベントストーミング

この方法論はDDD(Domain-Driven Design)に出てくる概念で、ドメインモデリングを視覚的に表現する方法です。構成員全員、文字通り全員が参加する必要があるそうです。

この過程で、私たちが開発しようとしているサービス機能をどうするか整理する作業が何度も発生しました。導き出すのが難しい部分や明確にすべき機能について、チームメンバー同士で継続的に議論しました。

その中で機能とサービスの流れが明確に整理され、イベントストーミングの過程は非常に重要だと感じました。特に、私たちのサービスは大規模サービスではないにもかかわらず、修正すべき機能や議論すべき部分が次々に出てきました。DAUやMAUはどうなるのか、DBは何を使うのか、どの技術スタックを使うのか、などです。

何より重要だと感じたのは、**「全員」**が参加しなければならないという点です。実際の会社で働くことになったら、特にスタートアップではこのように働くのかはわかりません。しかし開発は単なる技術ではなく、ドメイン知識、デザイン、CTO、開発者、マーケターに関係なく、全員が参加してドメイン領域を明確に引き出し、その過程で歯車が合わない部分を見つけて話し合い、修正していくことが非常に重要だと思いました。学生である今、負担なくこの過程を経験できることをとてもありがたく感じました。

イベントストーミングは3月27日と4月3日に行いました。思い出せる内容から書きます。まず、リカーショップ情報、酒類詳細情報、ウィッシュリストの推薦システム、カート機能についての話でした。

ユーザーはリカーショップや酒の名称を検索できます。リカーショップをクリックすると、そのリカーショップが持っている酒の一覧が出て、酒をクリックすると酒に関する情報と、その酒を保有している近くのリカーショップが表示されます。ここでユーザーは酒をウィッシュリストに入れたり、カートに入れたりできます。

ウィッシュリストは推薦システムマイクロサービスと連動しており、ウィッシュした酒について、位置ベースで最も近い店や価格面で有利な店を推薦します。しかし、リカーショップで酒を選択した場合は推薦する必要がないため、すぐカートに入れられます。そのため、リカーショップで酒を選択した場合はウィッシュリストと推薦システムが連動しないようにしました。ウィッシュリストで選んだ酒はカートへ移り、最終決済できるようにしました。

また、メインページのデザインについても話しました。文章で長く説明すると頭の中に同じ絵が描かれなさそうなので、上から下への流れとして番号で整理します。

メインページ上部左側にはロゴとサービス名があり、右上には検索アイコン、通知アイコン、プロフィールアバターがあります。
各アイコンをクリックすると、modalではなく新しいページへ移動します。
メインページhero領域では、ユーザーが先に回答した嗜好調査システムに基づく酒類と説明が左右に自動スクロールするデザインを入れようと思います。カルーセル形式のデザインを適用したいです。
その下には、ユーザー位置ベースで周辺バー、リカーショップを表示する領域がスクロール形式で出ます。
その下には、ユーザー位置ベースで観光情報や場所関連APIを組み合わせ、近くで自由に集まれる場所を推薦する領域が出ます。公園や川辺のような場所で軽くお酒を楽しむこともあるため、そのような場所の推薦です。
その下には、掲示板推薦記事や情報記事を表示する領域でメインページを終えます。

整理された内容

ログイン/会員登録はGoogle OAuthのみで進めることにし、一般的なログイン・会員登録formはありません。
事業者登録や公共機関への書類提出・認証が必要な決済、成人認証ロジックは、アプリが80%以上完成したら追加します。
ウィッシュリストで推薦システムと連動するのは、ユーザーが酒をウィッシュした場合のみで、リカーショップで酒を選択した場合はウィッシュリストと推薦システムが連動しないようにします。
メインページデザインは上から下へ:
1. 上部バー（ロゴ、検索アイコン、通知アイコン、プロフィールアバター）
2. カルーセル形式の嗜好調査ベース酒類推薦領域
3. ユーザー位置ベース周辺バー/リカーショップ推薦領域
4. ユーザー位置ベースで無料でお酒を楽しめる場所推薦領域
5. 掲示板推薦記事/情報記事領域

アプリデザインはStitch形式で既に実装されているため、そこまで気にしなくてよく、Notionでパートごとにデザインを上げ、変な部分や機能について議論しました。

おわりに

イベントストーミングは非常に重要です。
お互いに「この機能が必要だ」「その機能は別の方式で代替できる」「この方式のほうが良さそうだ」と話し続け、議論する過程が非常に重要です。
ドメイン知識が豊富な人がいると非常に楽です。欲しい機能や雰囲気についてすぐフィードバックしてくれます。
一人でイベントストーミングをするのは不可能だと思います。
個人開発とチーム開発の違いを明確に理解しました。

このシリーズは完成するまで継続して連載します。

Flutter実装のためのバイブコーディング
チャットサービスに関するブログ記事レビューや論文レビュー
推薦システムに関するブログ記事レビューや論文レビュー
開発中に遭遇した問題と解決過程
開発しながら感じたこと
開発しながら勉強した内容
開発中に参考にした資料など

Hun-Bot

On-The-Blockサービス開発記 01