Clean Architecture in TypeScript 

Yes I'm with you. This is also what I used to do but if we are pragmatic about it then the amount of effort it costs to decouple yourself from such frameworks doesn't seem to be worth it for your average application. Which is probably also the reason why we dont see this done often if at all in publically available source code. This is also the reason why I instead aimed on the minimal amount of effort to decouple the application layer from the infra layer(with the focus around your traditional picked http driver) Which again isnt the traditional take of CA hence I explcitly called it the "modern" take. Though in hindsight I should have added another slide on this considering it gives you the tools to truly decouple from such frameworks with ease of plugability. Edit: Also, it adds even more work when you use the likes of decorator based frameworks considering ts is lacking in that department.

Given the controllers don't do much, you can move DTOs to the application layer (which is fine according to some DDD people) and turn controllers into universal wrapper around use cases which let's say always reads request body and pass it as a UseCase input and returns UseCase output as a response body. In this case all the express code will be in one controller file

I'd love to see this a year ago.. Even though he's not right at everything, general concepts are all very well explained - very useful

That's the thing, what works for one, doesn't work for another. I prefer to prefix interfaces, others don't. Pick your poison

Yeah that's correct. Don't know your use case and requirements but we commonly use messaging systems to communicate between services. For example, a payment gets made, so we emit an event to our message broker -- and the service responsible for sending emails picks this up.

Can't recall the theme. Font is Dank Mono with some slight customization, line height is around 2~

Create an interface in your application layer and implement it in the infrastructure. Make sure that your interface has its own types. It's okay to name it specific to the service you are using or to be compeltely generic. It's up to you.

Yeah... I had it a tad too high. It seemed to cut off when I moved away from the mic. Definitely something I need to test properly the next time 😅

​@@donnyroufs551don't stress on it it's a type of thing where you become good with time only.

You can inject these use cases and use them, pipe them together or utilize an event bus. Sending an invite to me is a side effect so that's always done through an event if its on me. Placing an order can also be done through events if you want to loosely couple it. Ofcourse it always depends I don't know the context. If ordering and creating a user are both in a different domain then definitely events.

You can read the article written by the author himself on clean architecture but beyond that I dont have any specific resources. Github code search is always a gold mine.

ApiServer is just an example here. You can marry a framework and follow that (in the presentation layer) or do whatever you think fits best for your api. Try to imagine the presentation layer to be its own application and forget about CA, then when its time you hook the two up.