Developing software has friction, like machines do. Not enough information to do the right thing. Not enough resources to execute in the right way. And external factors influence fhe final outcome. So plan, design, and code for as far as you can see, but no further.

Don't jump into using microservices. Let the problems drive that decision. In reality, most of us will rarely justify the use of microservices.

Din't wait to code until you have a good model. But when coding, do it in small, frequent batches, enabling ease of change.

Don't do too much in a single transaction. DDD allows for only single aggregate manipulation per transaction. Use the outbox pattern to continue the logic.

Don't wait for long running jobs. Instead, return quickly with a JobHandle object, that can be used to track the progress of the job.

If you have "report generating jobs" in the back-end that provide no business logic (i.e. are only for front-end consumption), have the front-end send all (or most) of the data for the generation. Don't introduce new dependencies for this.

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.

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.

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.

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.