Curly Braces
@loopinglife.bsky.social
Daily nuggets of software wisdom.
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.
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.
August 23, 2025 at 5:46 PM
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.
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.
Let the problems drive that decision.
In reality, most of us will rarely justify the use of microservices.
August 11, 2025 at 3:41 PM
Don't jump into using microservices.
Let the problems drive that decision.
In reality, most of us will rarely justify the use of 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.
But when coding, do it in small, frequent batches, enabling ease of change.
August 7, 2025 at 2:47 PM
Din't wait to code until you have a good model.
But when coding, do it in small, frequent batches, enabling ease of change.
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.
DDD allows for only single aggregate manipulation per transaction.
Use the outbox pattern to continue the logic.
August 6, 2025 at 2:43 PM
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.
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.
Instead, return quickly with a JobHandle object, that can be used to track the progress of the job.
August 5, 2025 at 2:33 PM
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.
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.
Don't introduce new dependencies for this.
August 4, 2025 at 2:50 PM
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.
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.
They are derived technology from the OS.
And you'll understand them deeper by knowing Linux.
August 3, 2025 at 4:39 PM
Learn Linux before Docker, Kubernetes and AWS.
They are derived technology from the OS.
And you'll understand them deeper by knowing Linux.
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.
August 2, 2025 at 5:37 PM
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?
- 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?
August 1, 2025 at 2:59 PM
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?
- 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.
Even if it's a tiny change.
That way you can verify no business constraint is broken.
You can always optimize this later on.
July 31, 2025 at 2:20 PM
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.
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.
Their logic has nothing in common with the back-end's business logic.
Often it's even conflicting.
This is your start towards CQRS.
July 30, 2025 at 3:27 PM
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.
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.
Use: Request, Details, Configuration, Payload, Result, Specification, Item, Summary, ...or whatever this DTO actually represents.
July 29, 2025 at 12:20 PM
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.
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.
You'll have cleaner Services, and you won't forget to do it.
July 28, 2025 at 9:50 AM
Insert much of the validation logic inside Value Objects.
You'll have cleaner Services, and you won't forget to do it.
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 the logic becomes too complex, try to split it into multiple endpoints, with the front-end ensuring the whole workflow completes.
July 27, 2025 at 3:03 PM
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 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".
Only task-based UIs can specify "intent".
July 26, 2025 at 12:30 PM
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".
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.
Don't fit everything into a single "service" class.
July 26, 2025 at 11:38 AM
The application layer has multiple inner-layers of different responsibilities.
Don't fit everything into a single "service" class.
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.
It will reveal many subtle details on how the system should work.
July 25, 2025 at 9:47 PM
Write down a short essay explaining the system.
It will reveal many subtle details on how the system should work.
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.
Use an event when you want to inform of a change, but don't care who gets it.
July 25, 2025 at 1:56 PM
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.
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, ...)
Define different "actors" for the different contexts that User can be in. (e.g. Account, Employee, Profile, ...)
July 25, 2025 at 12:03 PM
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, ...)
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.
Bad interfaces "update" objects.
July 25, 2025 at 12:41 AM
Good interfaces present behavior.
Bad interfaces "update" objects.
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.
July 24, 2025 at 11:40 PM
"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.
July 24, 2025 at 10:51 PM
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.
The owner of queries is the front-end.
July 24, 2025 at 10:48 PM
The owner of commands is the back-end.
The owner of queries is the front-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.
July 24, 2025 at 10:45 PM
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.
July 24, 2025 at 10:42 PM
Good software design mostly means good dependency management.