A project in TypeScript is not much different from one in JavaScript structure wise. The biggest difference might be the explicit work on types and modeling your problem to make good use of composite types. In the source code you'll have some type definitions where implementation and usage sit close to each other (to enforce a local implementation), and others where a type is more like a serializable DTO (data transfer object) between different domains and seen more global throughout your application. You'll get a feeling when mapped types should alter a type or when a local type definition might be better (TS is structurally typed for a reason).
Domain modeling can feel close to "type driven modeling" here. A good book in that regard is "Domain Modeling Made Functional"[0]. I see types and a functional paradigm closely related, but keep in mind that this is just one approach in your toolbox... there might be the case where a GoF OOP pattern works good as well[1]. I think it's also important not to try to trick the TS compiler into something, but rather to work with it. Keep in mind that the TS dev team is giving you a lot of freedom by not striving for a provable correct type system[2].
To really take advantage of TypeScript I think it's good to know where a type system is coming from, what it is that it's trying to solve and how it is doing that. I think it's helpful to have a look into other languages with a "strong" type system (Haskell[3], OCaml, rust) and see how they are doing it. Then you may get to see how Haskells phantom types will conflict with TypeScripts type inference, and OCamls type inference seems to work in fascinating ways compared to TypeScript. After working through the advanced types[4] in TypeScript it's good to understand what a "good abstraction" in case of a type system is and what isn't... this is when you discover the similarities to other languages through the common language of abstract mathematics (and abstract data types). In every program you'll encounter effects and monads are quite helpful to work with them, this is were a sound type system can really shine.
I feel with every JS/TS project you will build a lot of the projects toolchain yourself and you kind of need to discover what fits best. It's good to be able to catch possible bugs early with the TS compiler, quicktype[5] can help you in building some typed contracts to other projects.
A separation into packages with lerna[6] should encourage a good separation into packages and is seen in a lot of open source projects. Speaking of, reading into good open source packages will be a mandatory way to go in order to learn more.
Unfortunately not. DDD is a design concept on how to match the business domain in source code - the design step is language independent and the practical implementation is very business dependent. I'm also keen to find a good practical reference, but can also understand why there might never be one. The book above on F# is very approachable, as F# in the predecessor of TS and the first half of the book is even language independent. Learning some SOA (service oriented architecture) terminology will be of some help as well.
I highly encourage you to not solely stick around JS/TS for patterns. For me, JS/TS is the "most" multi-paradigm language in usage to date, thus is not one of those languages that needs to be written in a certain way. Other languages can give you patterns more clearly and those are for the most parts adaptable to JS/TS. Haskell made it click for me on how to model with types, Elixir has the interesting concurrency/resilience pattern with supervisors etc... There are also good JS libraries whose usage still feels like programming and less "using a framework"-like - RxJS has an interesting approach for events/subscriptions and I feel like redux-saga showed me a very good use case for generators.
Domain modeling can feel close to "type driven modeling" here. A good book in that regard is "Domain Modeling Made Functional"[0]. I see types and a functional paradigm closely related, but keep in mind that this is just one approach in your toolbox... there might be the case where a GoF OOP pattern works good as well[1]. I think it's also important not to try to trick the TS compiler into something, but rather to work with it. Keep in mind that the TS dev team is giving you a lot of freedom by not striving for a provable correct type system[2].
To really take advantage of TypeScript I think it's good to know where a type system is coming from, what it is that it's trying to solve and how it is doing that. I think it's helpful to have a look into other languages with a "strong" type system (Haskell[3], OCaml, rust) and see how they are doing it. Then you may get to see how Haskells phantom types will conflict with TypeScripts type inference, and OCamls type inference seems to work in fascinating ways compared to TypeScript. After working through the advanced types[4] in TypeScript it's good to understand what a "good abstraction" in case of a type system is and what isn't... this is when you discover the similarities to other languages through the common language of abstract mathematics (and abstract data types). In every program you'll encounter effects and monads are quite helpful to work with them, this is were a sound type system can really shine.
I feel with every JS/TS project you will build a lot of the projects toolchain yourself and you kind of need to discover what fits best. It's good to be able to catch possible bugs early with the TS compiler, quicktype[5] can help you in building some typed contracts to other projects.
A separation into packages with lerna[6] should encourage a good separation into packages and is seen in a lot of open source projects. Speaking of, reading into good open source packages will be a mandatory way to go in order to learn more.
[0] https://fsharpforfunandprofit.com/books/ [1] http://loredanacirstea.github.io/es6-design-patterns/ [2] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [3] http://learnyouahaskell.com/ (a bit dated though) [4] https://www.typescriptlang.org/docs/handbook/advanced-types.... [5] https://quicktype.io/ [6] https://lerna.js.org/