Freedom hands a Go service its ports, adapters and a code generator

The pitch is ports and adapters, the cost is a stack

Freedom describes itself as a hexagonal architecture framework for Go, focused on supporting domain driven design, and its feature list is organised exactly that way. It claims a complete ports and adapters implementation, support for DDD practice, dependency injection with the dependency inversion principle, and a plugin design that it says is fully open to extension. On the model side there are aggregate roots, domain events, CQS for command query separation, and entities and value objects. That is a coherent position and it is not a neutral one: adopting the framework means adopting its idea of where a repository lives and how a transaction begins. Read the feature list as an argument rather than a set of facts, because those words describe an intention. The measurable version of the framework is in go.mod, which is where the actual dependency footprint becomes visible.

go.mod is the honest feature list

The module requires Go 1.25.0 and pulls in a specific stack: github.com/8treenet/iris/v12 at v12.1.9 for the web layer, gorm.io/gorm with the mysql and postgres drivers for persistence, IBM/sarama for Kafka, redis/go-redis/v9 for the distributed cache, prometheus/client_golang for metrics, spf13/cobra for the command line tool, go-playground/validator.v9 for validation, google/uuid, plus toml and yaml support. The Iris dependency is a fork maintained by the same organisation, so this is not a thin abstraction over a community web framework; the framework owns that layer. Two consequences follow. First, your service inherits a web framework, an ORM, a Kafka client, a Redis client and a metrics client whether or not you use the message queue or the cache on day one. Second, because the go.mod pins are explicit, the framework's release cadence and its dependencies' release cadence are now your upgrade planning. The README does not publish a compatibility matrix for any of this.

Scaffold, resolve, run

The quick start is a Go tool install and four commands. The CLI lives in a freedom subdirectory of the module:

$ go install github.com/8treenet/freedom/freedom@latest
$ freedom version

The install instruction ends in @latest, which is worth noticing on a framework that pins its own dependencies: there is no documented way to install a specific version of the CLI from that line. Scaffolding a project looks like this:

$ freedom new-project [项目名称]
$ cd [项目名称]
$ go mod tidy
$ go run main.go

The generated project is a Go module with a main package, so the usual go tooling applies and the go mod tidy step is what pulls the framework into your new go.mod. Nothing about the output structure is described in the README beyond the commands, which is why the example projects matter: example/base is described as the place where the DDD basics and the framework's core features are demonstrated, and that is the file to read before you decide the scaffolding fits your layout.

Three ways to generate a persistence object

The second CLI command generates the persistence layer, and it accepts three different inputs, which tells you the framework expects you to own the schema rather than infer it. From a live MySQL connection:

$ freedom new-po --dsn "root:密码@tcp(127.0.0.1:3306)/数据库名?charset=utf8"

From PostgreSQL, with a separate driver flag and a key/value connection string:

$ freedom new-po --driver "postgres" -d "host=127.0.0.1 port=5432 user=root password=123456 dbname=postgres sslmode=disable"

Or from a JSON schema checked into your repository, which is the one that fits a domain-first workflow:

$ freedom new-po --json ./domain/po/schema.json

The presence of the third path is the interesting design statement. Generating from a live database makes the schema the source of truth, while generating from ./domain/po/schema.json makes the domain the source of truth and the generated code a projection of it. The README also lists freedom new-po -h for the full option set, and a separate claim in the feature list that CRUD operations are generated automatically, which is the part to check against what the command actually produces before you build a maintenance story around it.

Two cache levels and a stampede guard

The data handling features describe a cache with two levels, an in-memory first level and a distributed second level, and an explicit guard against cache breakdown, the stampede that happens when a hot key expires and every request misses at once. The go.mod list constrains what the second level can be: go-redis/v9 is the only cache client in the dependency set, so the distributed level is Redis, and the README never mentions Memcached or any other backend. That is a sensible default and also a constraint for anyone whose infrastructure already standardises elsewhere. The harder question the documentation does not answer is coherence. With an in-memory level in front of Redis, a write in one process leaves the other processes' first-level cache stale until something evicts it, and the feature list names no invalidation channel, no pub/sub topic and no TTL policy. If the second-level entry is short-lived and the first level is per-request, the problem disappears; if the first level is process-wide, you need to know the eviction rule before you trust a read after a write.

Workers and Context keep the framework out of the domain

The most distinctive piece of the design is described as a non-invasive Context based on workers, and it has its own guide, doc/worker-guide.md, next to route, service, persistence object, HTTP client and DDD guides. The idea, as the feature list frames it, is that a worker carries the request context and whatever infrastructure handle the repository needs, so the domain layer can be handed a repository without importing the framework or the HTTP stack. That is the dependency inversion principle doing real work, and it is the part of the framework a DDD team will care about most, because it decides whether your aggregates can be tested without booting anything. AOP support is listed alongside it, which is usually where transaction boundaries and logging get attached in this style of framework. The trade is a convention you have to follow. If a team writes a repository that reaches for a global or a context value directly, the isolation breaks, and the framework will not stop it.

Read fshop before you read the feature list

Four example projects ship in the repository and they are the real documentation. example/base covers the DDD basics and the core framework features, so it is the smallest thing to read end to end. example/http2 demonstrates the HTTP/2 server configuration and the dependency inversion in practice, which matters because the framework claims HTTP and H2C support on both the server and the client side. example/infra-example covers the transaction component, writing a custom component, Kafka integration and domain events, which is the file that shows what the plugin design costs and buys. example/fshop is the one to evaluate the framework with: the README describes it as a complete e-commerce domain implementation covering CQS, aggregate root, entity and value object, domain events, the repository pattern and infrastructure integration. If your use case is anything with orders, that example is the closest match in the repository, and reading it is a better use of an hour than the feature list.

Apache-2.0, Go 1.25, and the alternative of no framework

The licence is Apache-2.0 with a LICENSE file at the root, so commercial use and modification are unencumbered, and the release history is regular: v1.9.11 in December 2025, v1.9.12 in January 2026, and v1.10.1 on 2026-07-20, with the last push to master on 2026-09-01. The alternative routes are worth naming. A microservice framework such as go-kratos or go-zero gives you the same layering and dependency injection with gRPC, service discovery and configuration management attached, at the cost of a larger opinion set you did not choose. The other route is the standard library, GORM and about two hundred lines of your own interfaces, which is what the repository pattern looks like before a framework formalises it, and which keeps your domain free of a framework release cycle entirely. Freedom's case is the tooling around the pattern: the CLI, the code generator, the cache levels, the worker context and the examples. Take it if that tooling is what you lack, not if what you lack is conviction about the architecture.

Editorial conclusion

Adopt Freedom if you are writing a Go service in the DDD style, if you already use Iris or do not mind adopting it, and if a repository pattern with generated PO code and a two-level cache saves your team weeks. Do not adopt it for a small service, since the framework brings a web framework, an ORM, a Kafka client, a Redis client and a metrics client with it, and go.mod requires Go 1.25.0. Verify first that the freedom CLI installs at the version you intend to pin, that the fshop example runs against your database, and which of the six guide files under doc/ your team will actually maintain. The project is Apache-2.0, the last release was v1.10.1 on 2026-07-20, and the last push to master was 2026-09-01.

Frequently asked questions

Official sources

1. 8treenet/freedom on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases