Curly Braces @loopinglife.bsky.social · 23/08/2025Developing 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/2025Don'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/2025Din'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/2025Don'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/2025Don'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/2025If 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/2025Learn 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/2025A good adapter demands no changes from the domain. 000
Curly Braces @loopinglife.bsky.social · 01/08/2025If 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/2025When 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/2025Separate 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/2025Don'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/2025Insert 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/2025Keep 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/2025If 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/2025The 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/2025Write 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/2025Use 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/2025Don'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/2025Good 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/2025If 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/2025The owner of commands is the back-end. The owner of queries is the front-end. 020
Curly Braces @loopinglife.bsky.social · 24/07/2025What 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/2025Good software design mostly means good dependency management. 020
Curly Braces @loopinglife.bsky.social · 24/07/2025The 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