I also got another reply which I will share:
I tend to separate logical layers out into separate projects even if
those layers are all going to be deployed in the same physical process.
This is partly to allow them to be tested in isolation - unit testing is
easier if the things under test can be tested in isolation. This is
particularly the case when using technologies like remoting, web
services or Windows Forms. It's nice to be able to test the business
logic without having to wire it up to a real remoting system, or plug it
into a Windows Forms application.
I'm not aware of any documented conventions for naming here. In fact I'm
not aware of any conventions at all... I usually make them up as I go
along, or go with whatever my customers want to do. I don't think it's
anything that has been prescribed.
On my current project, we have all the code in a namespace named after
the company, and then under this is a namespace for the whole
development project. (And I mean 'project' in the 'project management's
sense here rather than the VS.NET sense.) This is then divided into
sections for each of the VS.NET projects, so we have things like
Company.Foobar.DAL for the Foobar project's Data Access Layer. (And the
DAL itself is in a single VS.NET project.)
We've actually gone as far as separating out different pieces of
business logic into separate projects, so we don't have a single
LogicLayer component. But that's mostly because we have different
pieces in different physical places, so we had to do that. (But the DAL
component is actually shared by all of these projects.) But you
wouldn't go for the number of different projects we've got unless you
had a good reason to, so it's not such a good example. We've split
things up whenever we've had a specific reason to, and not otherwise.
So I would keep things in as small a number of projects as is practical,
but to remember that testing requirements are a good reason for
splitting things up. (Because it's much less practical to test a