Curly Braces

Learn Linux before Docker, Kubernetes and AWS.
They are derived technology from the OS.
And you'll understand them deeper by knowing Linux.

A good adapter demands no changes from the domain.

If a bounded context needs information from another bounded context to do an operation, ask yourself:
- Am I missing a concept in this context?
- Should I sync it locally (through events), or fetch it everytime?
- Do I have the right model?

When making changes, always reconstitute the whole aggregate.
Even if it's a tiny change.
That way you can verify no business constraint is broken.
You can always optimize this later on.

Which you choose will depend on the context.
• Is there only one consumer?
• Does it make sense to wait for a result?
• Which way do I want my dependencies to point?

Separate front-end queries in a bounded context of their own.
Their logic has nothing in common with the back-end's business logic.
Often it's even conflicting.
This is your start towards CQRS.

Don't use the generic "Dto" postfix when naming your DTOs.
Use: Request, Details, Configuration, Payload, Result, Specification, Item, Summary, ...or whatever this DTO actually represents.

Insert much of the validation logic inside Value Objects.
You'll have cleaner Services, and you won't forget to do it.

I guess you can see it that way.

The point is:
In order to specify your intent to the back-end, you must specify *what* you're doing.
Otherwise, everything's a generic update, and you can't chaing logic, policies or events to it.

Keep each endpoint's logic simple and small.
If the logic becomes too complex, try to split it into multiple endpoints, with the front-end ensuring the whole workflow completes.

In a nutshell: Instead of designing the UI to send a whole form with the latest data, you design it so specific parts are independently sent.

Why?
Because you can design better logic if you do ChangeUserEmail or DisableUser, instead of just UpdateUser with the same information changed.

If you want rich business logic on the back-end, you can't have a crud-based front-end.
Only task-based UIs can specify "intent".

The application layer has multiple inner-layers of different responsibilities.
Don't fit everything into a single "service" class.

Write down a short essay explaining the system.
It will reveal many subtle details on how the system should work.

Use a command when you intend to do a specific action, and follow through to the result.
Use an event when you want to inform of a change, but don't care who gets it.

Don't overuse the User class. It's there mostly for access control.
Define different "actors" for the different contexts that User can be in. (e.g. Account, Employee, Profile, ...)

Good interfaces present behavior.
Bad interfaces "update" objects.

"How do I eliminate the need for this dependency?" - a question that, more often than not, leads to a better design.

If the fulfillment of a command entails a new dependency between bounded contexts, you should probably split the command into two.

The owner of commands is the back-end.
The owner of queries is the front-end.

What makes an app, a "web" app, is just the tiny adaptive layer of controllers that transform the HTTP request into a command or query sent to the app.

Good software design mostly means good dependency management.

The front-end is good when it brings multiple disparate data into a single view.
The back-end is good when it separates that data into distinct, specialized modules.