go2o is a domain model for online to offline commerce rather than a shop you deploy

What the project actually delivers

Go2o is a Go language implementation of the O2O business model and its foundations, using Golang and gRPC. The description is more precise than a name suggests, so it is worth reading closely.

It supports online stores and offline stores, and covers multi-channel businesses, multi-store, products, specification SKUs, snapshots, orders, promotions, payment and distribution. The feature list in the README is essentially a domain map of online to offline retail, and the mention of snapshots and SKU specifications is a hint about the kind of problem it was built for: pricing and stock that differ between a web shop and a physical store, and an order that has to be reconciled against both.

The stated purpose is to use domain driven design for deep abstraction of the business, to support common O2O application scenarios, and to allow integration with legacy systems through an open API.

So the deliverable is a model plus a foundation, not a finished product. The project description calls it a business model and its foundations, and the README's own account of who uses it is a studio that wants a reference implementation rather than a deployment target. Anyone considering it for a real shop should read it that way.

The project also has a history and a person behind it. The README thanks a DDD expert at Tencent by name as the mentor behind the project, and there is a QQ group listed for contributors, alongside a todo list and a bug list in the docs directory where contributions are directed.

Four sides, and the split is the design

The architecture is described as four parts, and that split is the most useful thing in the README for anyone evaluating the project.

The first is the management center, which includes the platform management center, the merchant backend and the store backend. The second is the online store, described as a PC shop, a handheld device shop and WeChat. The third is the member center. The fourth is described in the Chinese text as a passport and service, which is the access and integration layer.

Read together, that is a multi-tenant commerce platform. The platform operator, the merchant and the individual store each get their own backend, the shopper reaches the business through a desktop browser, a mobile device or WeChat, and the membership and access layer is what the other three authenticate against.

The channels in the list are the interesting part for a Chinese market context. WeChat is a first class storefront rather than an afterthought, and the handheld device shop is the mobile web case, which is how most Chinese O2O businesses actually sell. The same business, the same stock, the same orders, three different doors.

The dependency list corroborates this. There is github.com/silenceper/wechat/v2 as a direct dependency, and github.com/tencentcloud/tencentcloud-sdk-go for the cloud provider side, alongside a pinyin library for Chinese text handling, which is the sort of detail that only appears in a codebase built for that market.

gRPC, sockets, NATS and etcd

The README explains the integration story in one sentence: through the Socket service you can develop for Android and iOS, and through the RPC service it is convenient to integrate with other systems. The go.mod file shows what that means in practice, with google.golang.org/grpc at version 1.67.0 and the protobuf runtime as direct dependencies, plus github.com/ixre/gof and github.com/ixre/alidayu.

The rest of the infrastructure is in the same file. github.com/nats-io/nats.go is the message bus, go.etcd.io/etcd/client/v3 at 3.5.16 is the service registry and configuration store, and github.com/gomodule/redigo is the Redis client, with bradfitz/gomemcache in the indirect list as a second cache client. github.com/robfig/cron/v3 handles scheduled jobs.

The persistence layer is gorm with the postgres driver, and there is a ClickHouse driver in the list as well, which suggests the project is built to write analytical data somewhere separate from the transactional database.

Two dependency choices are worth a comment. github.com/google/wire is Google's compile time dependency injection tool, and it is a direct dependency, which tells you the project wires its domain services through generated constructors rather than a reflection based container. And github.com/disintegration/imaging is an image processing library, which in a commerce system of this shape is there for product images.

The module requires Go 1.25.0, and the repository has a Dockerfile that builds with golang:1.25-alpine and ships on alpine, exposing 1427 and 1428.

Three services have to be running before the code starts

The run section starts with the environment, and it is the part that tells you what kind of system this is. You install PostgreSQL and create a database named go2o, then download the backup file go2o.sql from the docs data directory and restore it. You install nats. You install etcd, where a single node is enough.

That is a real deployment, not a script you run against SQLite. The schema is a dump rather than a migration set, which tells you how the project expects the database to be managed.

The build and run steps are short.

git clone https://github.com/ixre/go2o.git ./go2o
cd go2o && go mod tidy 
go run go2o-serve.go

The serve binary takes flags for both of its ports and for the infrastructure it talks to.

Usage of go2o-serve:
  -apiport int
        api service port (default 1428)
  -conf string
         (default "app.conf")
  -d    run daemon
  -debug
        enable debug
  -endpoint etcd endpoints
  -help
        command usage
  -mqs string
        mq cluster address, like: 192.168.1.1:4222,192.168.1.2:4222 (default "127.0.0.1:4222")
  -port int
        gRPC service port (default 1427)
  -trace
        enable trace
  -v    print version

The gRPC service is on 1427 and the API service on 1428, and the mqs flag points at the NATS cluster as a comma separated list, with a local default of 127.0.0.1:4222.

The README also recommends Docker Compose for a one command run, using the compose file in the container directory.

docker-compose up -f container/docker-compose.yaml

The container image sets GO2O_NATS_ADDR to point back at the host, keeps its configuration in a /data volume, and copies app.conf there on first boot if it is missing.

Using the API instead of adopting the whole model

The README makes a point that is easy to read past: through the open API you can integrate into legacy systems. Combined with the four-part structure, that gives a second way to use the project.

The first way is to adopt the model. You take the domain layer, the services and the storage, and you build your business on top of it, which is what the four backends and the three storefronts are for.

The second way is to keep your own system and use go2o as a service, which is what the open API and the RPC boundary are for. The membership and access layer is the natural candidate for that, since identity and permissions are the things a legacy system most often needs from outside and most badly implements itself. The gRPC boundary, the protobuf definitions and the apidoc.json file in the repository root all support reading it that way.

That distinction matters for the decision. The first path means taking on a GPL 2.0 codebase, its schema, its conventions and its release cadence. The second path means running one more service and depending on an API that the project versions at its own pace, which given the release history is a consideration in itself.

The Socket service for mobile clients is a third door, and it is the one that explains the repository's contents. There is an assets/ directory, a hooks/ directory, a script/ directory, a snapshot/ directory with a dashboard screenshot, and a wiki/ directory, which together suggest a set of front end assets and operational tooling rather than a pure library.

A GPL project whose releases come rarely

The licence is GPL 2.0, with the file at the repository root, and the project is not archived. The last push was on 2026-08-15.

The release history is what a reader should weigh. The tags are v0.8.0 on 2026-01-12, v0.7.0 on 2023-03-26 and v0.2.0 on 2020-12-16. The gap between 0.7.0 and 0.8.0 is close to three years, and the current version is still below 1.0.

The project is not dormant, and the difference between a dormant project and a slow one is worth being precise about. The go.mod requires Go 1.25.0, the container build uses golang:1.25-alpine, and the dependency versions are current ones, with grpc at 1.67.0, gorm at 1.31.1 and etcd client at 3.5.16. A codebase that still compiles against the current release of its own toolchain is being maintained, even if it is not being released often.

But a consumer has to plan around the release cadence rather than around the commit activity, and that is a real cost for anything that depends on go2o as a service.

The repository layout is a conventional Go service layout, with cmd/, internal/ and pkg/ at the top level, plus the supporting directories, and the documentation is where the maintainer tracks work, through docs/dev/todo.md and docs/dev/bug.md. A Docker file and a .drone.yml for continuous integration sit at the root as well.

The realistic way to judge this project is as a reference implementation of an O2O domain in Go, and the honest questions are whether its abstraction matches your business and whether the four-part structure maps onto the way your organisation is actually split.

Editorial conclusion

go2o fits a team that already has the O2O problem, meaning a business selling online and through physical stores, and that wants a domain model and an RPC boundary rather than a hand rolled set of tables. It is the wrong tool if you want a working shop, since the deliverable is a model and a set of services rather than a finished storefront. Verify first that the schema dump and the etcd and NATS dependencies match your deployment, and read the docs/dev/todo.md and bug.md files, which is where the maintainer records what is still unfinished.

Frequently asked questions

Official sources

1. Issues
2. ixre/go2o on GitHub
3. License: GPL-2.0
4. README
5. Releases