ecto-thinking

Ecto Thinking

Mental shifts for Ecto and data layer design. These insights challenge typical ORM patterns.

Context = Setting That Changes Meaning

Context isn't just a namespace—it changes what words mean. "Product" means different things in Checkout (SKU, name), Billing (SKU, cost), and Fulfillment (SKU, warehouse). Each bounded context may have its OWN Product schema/table.

Think top-down: Subdomain → Context → Entity. Not "What context does Product belong to?" but "What is a Product in this business domain?"

Cross-Context References: IDs, Not Associations

schema "cart_items" do
  field :product_id, :integer  # Reference by ID
  # NOT: belongs_to :product, Catalog.Product
end

Query through the context, not across associations. Keeps contexts independent and testable.

DDD Patterns as Pipelines

def create_product(params) do
  params
  |> Products.build()       # Factory: unstructured → domain
  |> Products.validate()    # Aggregate: enforce invariants
  |> Products.insert()      # Repository: persist
end

Use events (as data structs) to compose bounded contexts with minimal coupling.

Schema ≠ Database Table

Use Case	Approach
Database table	Standard schema/2
Form validation only	embedded_schema/1
API request/response	Embedded schema or schemaless

Multiple Changesets per Schema

def registration_changeset(user, attrs)  # Full validation + password
def profile_changeset(user, attrs)       # Name, bio only
def admin_changeset(user, attrs)         # Role, verified_at

Different operations = different changesets.

Multi-Tenancy: Composite Foreign Keys

add :post_id, references(:posts, with: [org_id: :org_id], match: :full)

Use prepare_query/3 for automatic scoping. Raise if org_id missing.

Preload vs Join Trade-offs

Approach	Best For
Separate preloads	Has-many with many records (less memory)
Join preloads	Belongs-to, has-one (single query)