Don't jump into using microservices.
Let the problems drive that decision.
In reality, most of us will rarely justify the use of microservices.
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?
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.
A good adapter demands no changes from the domain.
Learn Linux before Docker, Kubernetes and AWS.
They are derived technology from the OS.
And you'll understand them deeper by knowing Linux.
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.
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.
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.
Din't wait to code until you have a good model.
But when coding, do it in small, frequent batches, enabling ease of change.
