Sign in

Curly Braces

@loopinglife.bsky.social
1.9K followers 13K following 29 posts

Daily nuggets of software wisdom.

PostsRepliesMedia
Curly Braces @loopinglife.bsky.social · 23/08/2025
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.
02115
Curly Braces @loopinglife.bsky.social · 11/08/2025
Don't jump into using microservices. Let the problems drive that decision. In reality, most of us will rarely justify the use of microservices.
1200
Curly Braces @loopinglife.bsky.social · 07/08/2025
Din't wait to code until you have a good model. But when coding, do it in small, frequent batches, enabling ease of change.
0100
Curly Braces @loopinglife.bsky.social · 06/08/2025
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.
120
Curly Braces @loopinglife.bsky.social · 05/08/2025
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.
060
Curly Braces @loopinglife.bsky.social · 04/08/2025
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.
020
Curly Braces @loopinglife.bsky.social · 03/08/2025
Learn Linux before Docker, Kubernetes and AWS. They are derived technology from the OS. And you'll understand them deeper by knowing Linux.
0153
Curly Braces @loopinglife.bsky.social · 02/08/2025
A good adapter demands no changes from the domain.
000
Curly Braces @loopinglife.bsky.social · 01/08/2025
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?
030
Curly Braces @loopinglife.bsky.social · 31/07/2025
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.
020
Curly Braces @loopinglife.bsky.social · 30/07/2025
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.
030
Curly Braces @loopinglife.bsky.social · 29/07/2025
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.
2120
Curly Braces @loopinglife.bsky.social · 28/07/2025
Insert much of the validation logic inside Value Objects. You'll have cleaner Services, and you won't forget to do it.
160
Curly Braces @loopinglife.bsky.social · 27/07/2025
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.
170
Curly Braces @loopinglife.bsky.social · 26/07/2025
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".
180
Curly Braces @loopinglife.bsky.social · 26/07/2025
The application layer has multiple inner-layers of different responsibilities. Don't fit everything into a single "service" class.
150
Curly Braces @loopinglife.bsky.social · 25/07/2025
Write down a short essay explaining the system. It will reveal many subtle details on how the system should work.
090
Curly Braces @loopinglife.bsky.social · 25/07/2025
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.
251
Curly Braces @loopinglife.bsky.social · 25/07/2025
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, ...)
060
Curly Braces @loopinglife.bsky.social · 25/07/2025
Good interfaces present behavior. Bad interfaces "update" objects.
0122
Curly Braces @loopinglife.bsky.social · 25/07/2025
"How do I eliminate the need for this dependency?" - a question that, more often than not, leads to a better design.
0100
Curly Braces @loopinglife.bsky.social · 24/07/2025
If the fulfillment of a command entails a new dependency between bounded contexts, you should probably split the command into two.
030
Curly Braces @loopinglife.bsky.social · 24/07/2025
The owner of commands is the back-end. The owner of queries is the front-end.
020
Curly Braces @loopinglife.bsky.social · 24/07/2025
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.
030
Curly Braces @loopinglife.bsky.social · 24/07/2025
Good software design mostly means good dependency management.
020
Curly Braces @loopinglife.bsky.social · 24/07/2025
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.
050