In the scope of your specific focus, projects are separate build steps, allow you to reuse parts of your domain in other parts of your domain, allow for individual versioning, and enforce a one-directional dependency graph.
Each project will be compiled into its own DLL. If project B depends on project A, then when you build B, you're going to build A; after which B can be built using A's dll.
So why does that matter?
If you are building one monolithic application, it doesn't technically matter in how many sub-projects you split this codebase in. I'm not saying it's good practice, and I definitely am not advising you to do it, but in such a situation the benefits of project separation simply don't really provide a benefit other than allowing you to neatly group your classes, which you could technically also be doing via folders in your single monolith project.
The benefits of project separation begin to show themselves when you move away from the monolith example.
If you are building multiple applications (e.g. a web api and a winforms app), then you're definitely going to need to have at least two projects, as the build process for either of these is completely different.
More importantly, suppose these two applications are expected to use the same business logic. Rather than copy/pasting that logic in both projects, it makes much more sense to create a third project to represent the business logic, and have your web api and winforms projects depend on that business logic project. This allows you to reuse your logic in different consumers.
When you iteratively apply this process of creating new projects for reusable logic, you will end up separating each layer into its own project (at the very least). But you're probably going to end up with even more projects, e.g. when you separate your interface from your implementation (which is commonly split into separate projects), or your test suites, or ...
You could conclude that a project's purpose is defined by it being consumed by more than one "parent" project, but do keep in mind that this is a bit too strict to be a complete definition. Even if there's currently only one consumer of your business logic, it's still valuable to already split this off into a project of its own.
Good practice includes preparing for the future - but I suppose you could then also say that even better practice is being able to reasonably judge which preparations are warranted and which are overkill. As far as project separation goes, you should err towards it being a warranted preparation for future code flexibility.
If you ever decide to create a second consumer, you won't have to start the cumbersome process of separating the business logic from what is now considered the "first consumer" of that business logic. It's much better to have it separated from the start. This is why developers often generate projects for every layer in their codebase, as a first approximation of how the code can be built with reusability in mind.
Another benefit to using projects (as opposed to folders) is that you can enforce dependency order. When dealing with projects that depend on each other, it's impossible to create circular dependencies. If A depends on B, then B cannot also depend on A (if they do, then either you're doing something very wrong or they should really be one joined AB project).
Had you been using folders to separate your classes, then there would've been no protection against circular dependencies, class A can refer to class B which in turn can refer to class A.
So, to summarize:
- Projects maximize library reusability when there are multiple consumers (now or in the future)
- Projects are individually built and can be versioned as such
- Projects help you to enforce a one-directional dependency graph
So when should you create an extra project?
The correct though tautological answer is "when it's appropriate". In other words, when one of the mentioned benefits apply to your scenario.
And I just want to repeat here that good practice should also be applied in preparation for future changes (within reason).
It's so much harder to separate a monolithic project than it is to work with separate projects from the start, which means you should generally err towards separating your projects before you start actually needing them to be separated.
