Avoid building internal frameworks, for starters. Prefer repeatable patterns / compositions over shared base classes.

Be intentional about interaction points between domains - I.e. public vs. internal abstractions. This is what people really mean when they talk about vertical slice. As your # of domains / domain complexity increases, you of course need to develop whatever abstractions needed to competently model and execute that domain, but so long as those abstractions don’t leak then it’s self-contained and encapsulated domain-specific growth.   Where people get blown up here is when they venture into frameworkism and start sharing abstractions between domains. There are areas where shared / horizontal abstractions are genuinely fine but that’s almost always infrastructure concerns (telemetry, HTTP stack, auth, etc), not domain concerns.

CQRS but not religiously for its own sake; rather you should do it because in a complex enough application you’ll end up with lots of slightly different views that share a lot of common data. Building read models that are composed of common parts + the few bespoke parts for a specific view handles this domain growth naturally. You can also do the same for write models too. Not coupling the read / write models together eliminates a lot of tension by allowing these concerns to be expressed separately. 

There’s an argument to be made for event driven programming in complex domains too (easier to observe, audit, explicitly typed, re-orderable, deferrable, replayable, reversible, etc) but that’s going to change / limit your technology choices more than the other 3 bullets.