We are currently working on the architecture of our Salesforce DX project. We've got an extensive codebase of existing customizations and are planning to turn them into multiple Unlocked Packages to make everything more modular etc. Of cause, not everything is subject to be packaged, some features would stay unpackaged.
And the question is: should this be a single project (with multiple package directories inside and single Git repo) or a project per feature is more preferrable (multiple Git repos)? How would you manage dependencies between packages and unpackaged stuff?
Could you please advise?
The Salesforce cli can run from anywhere. But certain commands are required to executed in the context of a Salesforce project directory. This includes all commands that execute packaging, deploying code to an org, all of which drives any CI/CD process you might use.
As I imagine trying to arrange a CI process spread across multiple projects, each with their own project folders, it seems like it would be adding unnecessary complexity.
Fundamentally, unlocked packages were designed to share a single Salesforce project. So unless you've found a reason otherwise, going that direction is the right move.
The Salesforce developer evangelist team maintains a sample app that is built using the multiple package model called "Easy Spaces". I'd suggest looking in the sfdx-package.json file there to understand how to arrange and identify package dependencies.
You may be able to infer some ways to organise the code in your project accordingly.
How to make all those decisions is way too much for a single answer. But this youtube video is a customer development team leader sharing how they rearchitected their codebase to use unlocked packages.
If you have any problems as you get started, there are also a number of questions already asked on the Salesforce StackExchange site, too.