我想做一款让酒吧找艺人、艺人找演出的 App，名字叫“音乐酒吧街”。现在把商业思路、产品与后端设计、设计图和原型公开，愿意拿去落地，或者一起做，都欢迎。
目前有的是设计资料，业务后端还没写。公开展示用重新绘制的灰色线框原型，原有 UI 仅保存在本地。
一次合作怎么走
酒吧发布演出日期、预算、场地条件和艺人类型，艺人看需求、投递作品；酒吧也可以先看艺人资料，直接发邀请。两条路都进入洽谈。
投递意向和接受邀约不算成交。双方要谈清楚时间、费用、演出时长、设备和取消条件，再对同一版条件确认，平台才创建演出订单。有人修改条件，原来的确认就需要重新核对。演出结束后双方确认完成；取消、改期和争议另留记录。
这样做是想把一次合作记清楚，也为下一次合作留依据。只有聊天和联系方式，用户拿到后很容易离开。作品资料、可用档期、合作记录和复约能不能让人留下来，需要实际试。
先验证收费，不把统计当收入
最初考虑商家会员和按成交金额算 1% 服务费，两种都还没验证。会员可以试发布额度、需求管理和推荐展示，但基本撮合先要能用。
1% 看起来很低，也意味着收入不一定覆盖人工：一场演出 1,000 元，只记 10 元服务费；100 场才 1,000 元，还没扣获客、协调和云资源成本。向谁收、什么时候收、线下结算后怎么核对，都要先试清楚。
一期让酒吧和艺人自行结算演出费，平台记录合作。应收服务费和实际收到的钱分开记，不能把成交额或佣金统计直接当成平台收入。
后端先保持简单
一期设计为一个 Spring Boot 应用，按账号、资料、撮合、订单、媒体、消息、会员和只读看板划分模块。PostgreSQL 存业务事实，Redis 存验证码、会话和可重建缓存，开始可以同机部署。图片用阿里云 OSS，作品视频用阿里云 VOD。
双方确认条件、创建订单和占用档期，在同一个 PG 事务里处理。关键规则交给业务模块和数据库约束，避免只靠前端校验。消息先存 PG、按游标读取，后续有实时需求再接长连接或第三方 IM。
媒体、通知、支付和 IM 留适配接口；一期不先拆微服务、不单独建管理员服务，也不预先部署消息队列。资料审核和下架放在各模块的受控运营接口里，保留操作者和原因，看板只读。
开放了哪些资料
现在有完整的产品与后端设计文档、10 张设计图、16 张低保真原型，以及页面职责说明。文档细化了数据、状态、权限、接口、上传、消息和部署，并保留需要现实合作验证的问题。
文档和设计采用 CC BY 4.0，网页源码采用 Apache-2.0，可以按许可修改、开发和商用，不需要给我分成。
如果有同城酒吧、艺人或运营资源，我觉得可以先人工跑几次合作，观察需求是否清楚、投递是否合适、谈定要多久、能否顺利完成、下次是否还愿意用。这比下载量和 Star 更能说明该不该继续投入。想一起做，可以在 GitHub Issues 留言，说下你能做哪部分、想先试什么。
文中提到的产品
暂无关联产品