很长一段时间里，摆在我们面前的问题看起来像是一个采购决策。销售渠道在不断增加，库存在各个平台与仓库之间分散，而"我们到底有多少货"这个问题的答案，取决于你去问谁。最直接的做法，就是买一套更大的系统。
我们确实按这个思路试过：比较那些能装下更多 SKU、更多店铺、更多对接的平台。它们都回答了某个版本的问题，但没有一个回答我们的问题。
问题从来不是"该买哪一类软件"
ERP 的前提，是一家已经清楚自己拥有什么的企业：干净的主数据、一个存放事实的地方、基本在一个组织内部运行的流程。当你的业务就是一个目录、通过一两个渠道销售时，这套模型非常有效。
我们的现实完全不同。同一件实物商品，会在多个平台以不同的 Listing 身份存在，来自不同的供应路径，并在不同时间以不同格式上报库存。采购单、平台 Listing 与仓库库位是三种对象，有三种生命周期。把这些压成同一行数据的软件并没有错——它只是在回答一个比我们更简单的问题。
我们要构建的东西
WEOUR OS 是一套 Commerce OS：一组系统，用来描述商品、Listing、仓库与决策之间的关系，并在业务运行的过程中让这些关系保持真实。
- 层
- 职责
- 渠道
- 每个店铺保留自己的身份、定价规则与 Listing 生命周期
- 库存
- 观测值记录来源与时间，不做静默合并
- 仓库
- 物理库位作为一等记录建模
- 映射
- SKU、Listing 与商品身份被关联，而不是被假定为相同
- Agent
- 自动化依据明确的系统规则提出建议并执行
每一层都可以被替换，但关系不能。
在生产环境里构建，而不是在幻灯片里
这篇内容以构建日志、而不是成果发布的形式出现，原因是我们并不是从白板开始的：我们改动的是已经承载真实店铺、真实仓库和真实 Listing 的系统。每一个设计决定，都要在它被做出的同一天经受真实业务的检验。
这个限制让人不舒服，但很有用：它排除了无法增量上线的漂亮架构，也迫使我们把业务早已在默认遵循、却从未被明确写下来的规则写出来。
这对你正在看的这个商城意味着什么
weour.com 不会被一个新网站取代，它本身就是系统之一。商城主站、俄语与中文市场渠道、供应商流程，以及内部运营层，正在被纳入同一套关于"店铺、商品与库存状态究竟是什么"的模型。
一套面向全球贸易的操作系统，不是更大的数据库，而是更少的、可以被信任地遵循的规则。
接下来
这个日志的后续内容，会写我们最难处理的部分：店铺如何在共享一个商品目录的同时保持隔离；为什么新增店铺不能复制库存；当占位库位遇到真实库位时发生了什么；以及为什么未知库存永远不会悄悄变成 0。
这就是我们正在构建的东西，我们会持续公开。