Tactical Design

Value Objects should never change after creation. Any 'change' should produce a brand-new object instead of altering the original. So Money.add() should return a new Money with the summed amount, not modify the original — that way nothing else holding a reference to the original gets silently surprised.

Validation checks an object after it exists. Construction-to-order uses the same rule before building, to describe exactly what a new object should look like so a factory can build one that already satisfies the rule, instead of building something and then rejecting it.

You write down, in the code, exactly what must be true before and after the change (e.g. 'balance can't go negative') so anyone reading it knows the rule without guessing. But Java's built-in assert is switched off by default in production, so if that's your only check, the rule silently stops being enforced.

If one aggregate's code directly calls another aggregate during an operation, you've merged their boundaries and lost the point of splitting them. Coordination should instead happen one level up, in application code that orchestrates the use case.

Neither Account owns a transfer between two accounts, so it doesn't fit as one entity's method. A stateless domain service takes both accounts and the amount, applies debit/credit rules, and returns the results — holding no data between calls.

Specific events tell listeners exactly what happened, so they can react directly without inspecting the data. A generic 'Updated' event is easier to add but forces every listener to figure out what actually changed by digging through the payload.

A 'thin' event carries just the key IDs and what changed, like an order ID and new status. A 'fat' event carries the whole aggregate's data. Thin events are smaller and less likely to leak stale info; fat events save listeners an extra lookup but can go stale or expose more than needed.

No - a real Domain Service covers one business process, not everything vaguely Order-related. This is a dumping ground that hollowed out Order. Fix it: move Order's own logic back onto Order, split the rest into small, named services.

If a user's identity IS their email, then changing the email means the user 'becomes a different user' as far as the system is concerned — any records referencing the old email (orders, permissions, links) lose their connection. A separate, unchanging ID (like a random UUID) fixes this because the ID never changes even when the email does.

For something that small, a factory is overkill - a simple constructor or static function that checks the email format is enough. Factories earn their cost only when creation is genuinely complicated, like needing several steps, other data, or business rules that could easily be gotten wrong.

When aggregates get big, a method that looks as simple as 'find this order' can secretly load a huge amount of data or run many slow queries behind the scenes - the simple-looking interface hides a performance problem that only shows up once you have a lot of data or traffic.

Instead of letting callers build raw database queries through the repository, you give the repository a small number of named methods that describe what business question is being asked (like 'find overdue orders'), or you move heavy reporting needs to a completely separate read-only layer that doesn't pretend to be the domain repository.

A single yes/no doesn't tell the user WHY something failed. So instead of just isSatisfiedBy returning false, you add a way for each sub-rule to report its own failure reason, and collect all of them into a list the user can actually read.

If combining two things of a type gives you back the same type, you can chain operations endlessly (add, add, add) without ever stepping outside that type into something less meaningful, like a raw number that's lost its currency and rules.

Yes, when a rule needs to look across many records, like checking an email is unique. The line: depend on an interface defined by the domain, never a concrete database or HTTP class, and never let query details leak in.

Specifications add extra classes and indirection. If a team uses them for every tiny check, the codebase gets harder to read and navigate for little benefit. Use them where rules are genuinely reused, combined, or need to become queries - not everywhere.

When a rule can never be broken, even briefly, keep its data in one aggregate so one lock guards it. If that's too slow, speed up or queue that path — don't loosen the guarantee.

The business logic should just record that an event happened — not broadcast it. The application service should send it, and only after the database changes are safely committed, so nobody hears about something that later gets rolled back.

If nothing outside the aggregate actually needs to react, and it's a simple internal check like 'balance can't go negative,' don't make it an event - just check it directly in the method. Events are for facts something else cares about, not for every little internal rule.

No — Order is still an Entity because it still has one identity across its whole life. The snapshots are a different, separate thing: each snapshot is a Value Object (immutable, no identity of its own) that just describes 'what the Order looked like at this specific point in time,' tagged with the Order's id and a timestamp.

Split it into steps: first reserve or hold the stock on each product (separate small transactions or a reservation step), then create the Order only if all reservations succeed, using its own transaction. Don't try to change the order and all the products at once - use short-lived holds and a way to release them if something fails partway through.

You draw a line based on whether something needs a full business object to make decisions with (that stays with the repository) or just needs to show/report data (that moves to a simpler, faster read-only path) - and you keep re-checking that line as the system grows, because there's constant pressure to blur it for convenience.

A class that depends on almost nothing else is easy to understand and test on its own. But if you go too far and strip out every relationship, you can end up hiding real connections between concepts that the domain actually needs, making the bigger picture harder to see.