Erlyc Erlyc

Entity models

An entity model is the map of the things your application manages — customers, orders, invoices, whatever your domain is made of — with the attributes each thing carries and the relationships between them. It is the same idea an entity-relationship diagram (ERD) expresses, drawn before any table exists.

Why model entities before writing code

Most expensive software mistakes are data-model mistakes: a relationship that should have been many-to-many, an attribute bolted onto the wrong entity, a missing link that later demands a migration and a rewrite. On a diagram, each of these is a thirty-second fix. In a live database with dependent code, each is a project of its own.

How Erlyc builds one from plain language

You never draw the first version yourself:

  1. Your idea, refined through the discovery boards, becomes a locked specification.
  2. Opening Architecture & Code derives the entity diagram from that specification: entities, attributes, relationships — including the User → Role → Permission access backbone every generated application carries.
  3. You review and edit on the canvas: add entities, move attributes, redraw relationships. Nothing is saved until you save explicitly.

What the model becomes

The entity model is the single source the rest of the pipeline derives from:

  • The Database tab turns it into a relational schema — tables, columns, foreign keys — exportable as SQL.
  • The Models tab turns it into Eloquent models with their relations.
  • The Laravel tab generates a complete codebase whose screens, policies and navigation respect it.

Change the model and regenerate, and the schema, models and code follow. That direction of travel — meaning first, tables second — is the whole point.

Examples & tips

  • Name entities in the singular, after the language your users actually speak ("Shipment", not "shipping_records").
  • If an attribute keeps wanting to appear on two entities, it usually belongs on a third one you have not named yet.
  • Keep an eye on relationship directions during review: "an Order has many Invoices" and "an Invoice has many Orders" produce very different applications.