Can a layer consist of multiple projects / dlls?

Question

I am working on the architecture for a new web application and I am pretty much a complete newbie when it comes to architecture. Working my way through .NET Application Architecture Guide, 2nd Edition and learning a lot. I have decided to go for the "standard" 3-layer architecture: Presentation layer, Business layer, Data layer. Will be using ASP.NET MVC and Entity Framework.

Currently the business layer contains the logic and business entities (anemic models). I am planning to use the business entities as EF entities. That would, however, cause the data layer to have a depency on the business layer. This "problem" can be solved by moving the business entities into its own project and have the layers that have dependencies on the business entities reference that project.

1. Is that an ok / good way of doing things?
2. Will / can / should the business entities project be considered part of the business layer?
3. Can a layer consist of multiple projects, that is, the layer only acts as a "logical container"? In the above mentioned book they talk about how the business layer can consist of "Business Workflow", "Business Components", "Business Entities", and I assume that each of those are a separate project (maybe even multiple projects)?

Answer 1

1. Is that an ok / good way of doing things?

Sure, there's nothing within that guidance that says you can only use one project per layer. For anything beyond a small application, you're going to want to separate things out into their own projects.

2. Will / can / should the business entities project be considered part of the business layer?

Absolutely. Even though you'll have multiple projects per layer, you still need to organize the projects by their logical role. So all business layer projects should be named and organized in a similar way.

3. Can a layer consist of multiple projects, that is, the layer only acts as a "logical container"?

Yes again.

You will likely end up with some "core" projects within your layers. These are the projects you create in order to avoid the circular dependencies you mentioned in your question. And it's okay to have a "business layer core" as well as "business layer application function" type projects. All of them belong to the business layer. Repeat as necessary for the other layers.

The important thing to keep in mind is to continue to observe the separation between layers that this architecture introduces. Each project within each layer needs to obey the separation of concerns rules you put in place regarding what the project is allowed to reference.

For example, don't allow a Presentation layer project access a Data layer project. It's a little harder because now you have more projects to apply that governance to, but if you use a consistent naming convention or project structure it's pretty easy to do.

Answer 2

While there is nothing inherently "wrong" or "bad" with what you describe, it is generally preferable to use an architecturally evident coding style in which the structures in your code accurately reflect the structures in your architecture. That said, there is nothing wrong with having multiple projects within a layer. This may actually be a good thing -- as long as it is a conscience decision and not an accident.

Generally with the layered style, dependencies should only go "down", meaning a layer above may depend on layers below (how far the dependency goes down is up to you, some say only one layer, others allow the whole stack), but a layer below may not depend on a layer above.

In an ideal world, your layers should be "vertically sliceable" by feature or business object or similar. If you draw a dependency diagram and they look like spaghetti -- especially if the spaghetti crosses layer boundaries -- you may want to rethink how you are partitioning your system.