Comparison with Other Tools

Overview

Vandor takes a different approach from most Go backend tools. Instead of generating a full project upfront or acting as a runtime framework, Vandor follows a core-first model: you start with domain logic and layer on infrastructure as you need it. This page compares Vandor v0.4 with the most common alternatives in the Go ecosystem.

Quick Comparison

Detailed Comparisons

Vandor vs Go Blueprint

Go Blueprint is a popular project initializer for Go backends. It asks you a few questions and generates a project with your chosen framework and database.

Where they overlap:

• Both are CLI tools for Go projects
• Both generate code you own
• Both support multiple architectures

Where they differ:

Choose Go Blueprint when you want a quick project starter and plan to structure everything manually from there.

Choose Vandor when you want DDD guardrails, ongoing code generation, and the ability to add infrastructure incrementally.

Vandor vs Goa

Goa uses a Go DSL to define your API, then generates server and client code from that definition.

Where they overlap:

• Both generate Go code
• Both support structured API design
• Both can produce well-organized projects

Where they differ:

Choose Goa when API-first design is your priority and you want server + client code generated from a single source of truth.

Choose Vandor when domain modeling matters more than API contracts, and you want to choose your transport layer independently.

Vandor vs Buffalo

Buffalo is a full-stack Go web framework inspired by Ruby on Rails. It provides routing, templating, database tools, and more.

Where they overlap:

• Both have CLIs for scaffolding
• Both support code generation
• Both aim for productive Go development

Where they differ:

Choose Buffalo when you want a Rails-like experience in Go with built-in frontend support.

Choose Vandor when you want a backend-focused tool with no runtime framework dependency and DDD-first architecture.

Vandor vs Standard Library

The Go standard library (net/http, database/sql, etc.) gives you everything you need to build a backend from scratch.

Where they differ:

Choose the standard library when you have a small project, prefer zero abstractions, or want to learn Go fundamentals.

Choose Vandor when you want structured project organization, faster scaffolding, and the option to add infrastructure without reinventing the wiring every time.

Key Differentiators

What sets Vandor apart from all of these tools:

1. DDD-First Design

Vandor does not just support DDD -- it is built around it. Contexts represent business capabilities. Use cases live inside those contexts. The directory structure enforces domain boundaries.

# This is the primary workflow: model your domain first
vandor add context catalog identity order
vandor add usecase catalog create_product list_products
vandor add service identity auth_service

2. Core-First Development

Your project starts with domain logic, logger, and config. Nothing else. HTTP servers, databases, caches, and queues arrive only when you install them.

# Start clean
vandor new --module github.com/acme/myapp --tidy auto

# Add infrastructure when you actually need it
vandor vpkg add @official/http-humachi
vandor vpkg add @official/entgo

3. The VPKG System

VPKG is not a traditional package manager. It copies code into your project -- like shadcn/ui for Go backends. You own the code, you can modify it, and there is no hidden abstraction layer.

Packages also provide actions (scaffolding commands) and aliases (project-level shortcuts), so they are not just library code -- they are workflows.

4. Runtime Independence

Once your project is generated and built, the Vandor binary is not needed. Your Go application runs on its own. No framework runtime, no CLI dependency in production.

Code Generation Model

Understanding how Vandor generates code helps clarify the comparison:

The key insight: Vandor generates domain scaffolding and FX wiring. VPKG copies infrastructure code. You write business logic. The sync command only touches *_gen.go files, so your hand-written code is always safe.

Feature Comparison Table

Architecture Support

Developer Experience

When to Choose Vandor

Vandor is the right fit when:

1. DDD is a priority -- You are building complex business logic and want domain boundaries enforced
2. You want incremental infrastructure -- Start minimal, add packages as your requirements grow
3. You value code ownership -- No framework lock-in, no hidden abstractions
4. You need ongoing scaffolding -- Not just project init, but continuous code generation as your project evolves
5. You want diagnostics -- The doctor command catches problems before they become bugs

Vandor is probably not the right fit when:

• You need a simple CRUD API with no domain complexity
• You want a full-stack framework with frontend support
• You prefer API-first design over domain-first design
• Your project is small enough that manual setup takes less time than learning a tool

Getting Started

Ready to try Vandor?

# Install the CLI
go install github.com/alfariiizi/vandor/cli@latest

# Create a project
vandor new --module github.com/acme/myapp --tidy auto

# Add your first context
vandor add context catalog

# Install HTTP infrastructure
vandor vpkg add @official/http-humachi

# Start developing
vandor dev:app

See the Quick Start Guide for a complete walkthrough.