Tactical Design

An application service coordinates a use case — starts transactions, checks permissions, calls objects, converts data — without deciding business rules. A domain service holds business rules that don't fit one entity, like a rule spanning two accounts.

A domain event is a note that something meaningful already happened in the business, e.g. 'OrderShipped'. It's named in the past tense because it records a fact that occurred, not a request asking for something to happen.

A Domain Service holds business logic that doesn't fit on one specific object. You use one when an operation needs several objects together, or is really an action rather than a 'thing' - like transferring money between two accounts.

An Entity is something with its own identity that stays the same over time even if its details change — like a person has one ID for life. A Value Object has no identity of its own; it's just described by its data, so two Value Objects with the same data are treated as equal and interchangeable.

Because creating some objects takes several steps and rules that must all be checked together; a factory does that work in one place so every part of the code creates the object correctly and never ends up half-built or invalid.

A repository is a piece of code that lets the rest of the app save and fetch domain objects (like 'add this order' or 'find order #5') without knowing or caring whether they're stored in a database, a file, or memory - it just feels like working with a list.

A Specification is an object that holds a business rule ("is this order overdue?") and can answer yes/no for any candidate. Instead of copy-pasting the same if-check in five places, you write it once as an object and reuse it everywhere.

A name (of a class, method, or interface) should tell you what it does and why, not how it's built inside, so you can use it correctly without reading its guts. isOverdue() says exactly what you get back; checkFlag() forces you to go read the code.

Include only what must change together, at the same instant, to keep one business rule true. Keep aggregates small: fewer things bundled together means fewer collisions when different requests try to change the same aggregate at once.

An application service starts the transaction, checks the caller is authorized, calls domain objects in order, and converts results to an API shape — but never decides business rules; those live in the domain objects it calls.

The aggregate keeps a private list inside itself. When its business method changes state, it also adds an event object to that list. Some outside code (like an application service) reads the list after the method returns and publishes the events - the aggregate itself never talks to any bus.

Name the service after the business action it performs, using words business people use - not generic tech words like Manager or Helper. If you can't explain the name in one sentence, it's not a real domain concept.

If equals() only checks the id and the id is null before saving, then two different unsaved orders both look 'equal' or the equality logic becomes unreliable, which can cause objects to get lost in Sets/Maps once the id is assigned. Teams usually fall back to comparing object references until an id exists, or generate the id in code (like a UUID) before saving so it's never null.

Use a method on the object itself when creation only needs data already going into that object; use a separate factory class when creation needs outside help, like other aggregates, ID generators, or several related objects built together.

Making something new has to check business rules like 'is this order allowed to exist yet,' but loading something that already existed and was already checked once shouldn't re-run those creation-time checks - it should just rebuild the object from stored data.

You only build a repository for the 'root' object of a cluster of related objects (like an Order, not its individual OrderLine items), because that root is the only safe entry point - going around it to touch the inner pieces directly can leave data in a broken, inconsistent state.

Persistence ignorance means your core business objects (like an Order) don't know or care how they're saved - no database annotations, no SQL, no ORM-specific base classes in the domain code itself. The repository is where that knowledge lives instead, kept out of the model.

You can glue simple rules together like Lego: "expensive" AND "overdue" makes a new rule that's true only when both are true. Each combined rule is itself a Specification, so you can keep combining without ever rewriting the original checks.

A query just answers a question and changes nothing; a command changes something and doesn't need to return an answer. Keeping them separate means you can call a query as many times as you like without worrying it will break anything.

Only the aggregate root's own methods can change its data — no direct field edits. Each method checks the rules first, then the whole change saves as one atomic write, so nothing half-valid is ever stored.

This is the anemic domain model anti-pattern — entities hold no behavior, logic piles into services. It happens because adding one more 'if' is easier than redesigning the entity. Fix: move each rule to the object owning its data.

You can make the listener run in the same transaction so both aggregates change together, or let it run after the transaction commits so they change separately. Same-transaction means both always agree, but couples them tightly. After-commit means they're looser, but for a moment one might be out of date.

Each Account should only protect its own balance rule, like not going negative. A transfer touches two accounts, so a separate FundsTransferService coordinates withdraw on one and deposit on the other, rather than one account controlling another.

Ask: does the business need to track this specific instance over time and tell it apart from an identical-looking one, or does it just describe a value that's interchangeable if the details match? An address used just to ship a package is usually a Value Object (only the street/city/zip matters). But if a 'Verified Address' needs its own approval history and audit trail, it becomes an Entity with its own identity.

The balance check only needs the data you're already given, so the factory can check it instantly by itself. The email-uniqueness check needs to look at other accounts somewhere else, so the factory has to ask something outside itself - and that check can go stale between asking and actually saving.

Checking one object in code and asking a database "give me all matching rows" are different jobs. If you write the rule twice - once as code, once as SQL - they can drift apart. Teams solve this by having the specification generate the query itself instead of writing it separately.

Instead of splitting the method by lines of code or by what's easy to test, split it along the real concepts the business already thinks in, like 'base rate' vs 'express surcharge' vs 'insurance fee', because those are the pieces that actually change independently over time.

A domain service can be tested with plain objects — call it and check the result. An application service usually needs mocked or fake repositories to test, since its job is coordinating things, not doing the business math itself.

A Domain Service shouldn't remember anything between calls - each call gets everything it needs as input. If it stores data in its own fields instead, two concurrent calls can mix up or overwrite each other's data.