Nathan Ladd's wroclove.rb 2018 talk, delivered as the first event-sourcing talk of the conference. Opens with a review of event sourcing: reframing web forms as command messages, comparing a typical MVC+ORM command flow (retrieve model → apply changes → validate → save → cascading callbacks) to the event-sourced flow (project entity → accept/reject → write event). Explains projection as sequentially folding events for a single entity starting from empty state. The bulk of the talk critiques four anti-patterns teams hit when adopting event sourcing, all stemming from continuing to perceive software through an ORM lens: (1) entities coupled to messaging — entities that take command messages as parameters, interpret their attributes, and return events become unusable outside event sourcing and lose cohesion; keep entities as pure core business logic so they could be swapped to an ORM without change; (2) view-biased event schemas — stuffing UI-only fields like a category_id into events to make materialized views easy; events should record only what occurred, and views should be composed from multiple streams with additional aggregation techniques; a variant is reusing a Rails-style errors object, which leaks UI dispositions (negative vs positive) into the domain (an overdraft isn't an 'error' to the bank that charges a fee); (3) opaque dependencies — frameworks that hide the projection by passing an already-projected entity into the handler (beginners can't find the event sourcing, caching/strategy can't be controlled except via global configuration), situations where no entity is needed at all (email uniqueness via a reservation event, updating materialized views, telemetry handlers), and opaque writers where the handler returns events instead of writing them (concurrency countermeasures like 'expected version' cannot be applied per-case, and failures to persist after irreversible external side effects like Stripe charges become very bad); handlers must control their writer just as they should control all dependencies (substitute writers make handler tests never hit the database); (4) the aggregate-root class pattern — mixing entity, handler, and projection responsibilities into one class for convenience, which Ladd has seen cause real damage at multiple clients and which forfeits the big testability wins of event sourcing (isolated entity tests, isolated projection tests, handler tests that assert on what was written). Posits that aggregates are popular because many web developers are uncomfortable with object-oriented structural design and prefer to stuff everything into a subclass of a framework artifact; the 'we'll refactor once we know the boundaries' justification is backwards — coding is not how you learn what the system should be. Closes with warnings about community and thought-leader worship (communities can suppress critical thinking; rails-better-than-rails communities still ship god classes), the reminder that tooling never forced anyone to build a monolith, contextualized complexity (your OS, Ruby VM, and web browser are all very complex but you only deal with a small subset at a time), and 'measure twice, cut once' — spending a week of up-front design on one service is not waterfall, even if the community now finds 6–18 minutes of design uncomfortable. Q&A covers: what an entity is (a data structure with domain-specific methods, sometimes logical like an account microservice); whether the account's sufficient-funds check is a feature-envy smell (the conditional legitimately belongs in the handler because deciding which message to write is a messaging concern); the biggest challenge (you will never prototype as fast as Rails); idempotence and transactional integrity with external systems (the handler is authoritative when it owns the data; external calls belong in the handler and need idempotence patterns); event ordering across distributed systems (use vector clocks, but teach the underlying problem first); whether Rails adopters write handlers instead of controller actions (prefer writing the command to a stream if planning to go micro-services — portable across Rails/Hanami); event versioning (hard — in monoliths you publish new versions and branch on read; in micro-services you can rebuild the whole service and transform old events into new commands; best answer: don't make the mistake, and learn from mistakes instead of switching languages); centralised vs per-service event stores (event stores have no cross-stream associations, so a shared physical store is fine — split only for operational reasons like scale); whether events store current state or just changes (events are raw occurrences; current state is folded from them, cached via per-version cache records, and periodically snapshotted for streams with millions of events); GDPR (regulations are part of the business domain, not the framework).