In my opinion, mixing interfaces for services and repositories in one project is not a good idea. Doing so will expose unnecessary interfaces to projects that don’t need them (e.g. DAL doesn’t need to know about service interfaces, UI doesn’t need to know about repositories interfaces in strict layering)

Below is a common structure that I use frequently in my layered applications. It’s a reference from books (Professional ASP.NET Design Patterns to be more specific) and some online articles with my own modification

This structure has 4 layers that commonly found in DDD: UI -> Application Services -> Domain (Entities + Domain Services) + Repositories. The central of the application is Core project where it contains all business logic, business entities and interfaces for repositories (to be used by application services). ORM/Data Access logic is encapsulated in Repository project. UI only depends on application services interfaces. Here I assume you use IoC container for dependency injection with UI project as composition root.

Beside the projects listed here, of course you can have additional projects like:

• Infrastructure: infrastructure related, e.g. logging
• DependencyResolution: move IoC container setup code here if you don’t want to put in UI project

The implementation seems to be fine as in a traditional N-Layer architecture.

• In strict layering your UI layer will always call BLL, which will then call DAL, UI cannot call DAL directly.
• In case there is not much business logic you can directly call DAL from UI and completely avoid BLL.
• You can also have a mix, business logic in BLL, UI calling both BLL and DAL directly in some scenarios where it makes more sense that is what is known as loose layering.

However regarding CORE (Interfaces), I think you should NOT have BLL and DAL interfaces grouped together. Imagine strict layering, in that case you will may not like to expose the DAL interfaces to UI.

I can see few potential issues with this approach,

1. Having all DTOs in one project,
   If you have a DTO used in your presentation layer why would you want to put it in your core assembly, rather I’d put them where they belong

2. If the BLL is the domain model, its fine, but if services are living there too, I’d rather move them to service layer between UI and DAO.

Ideally,
1. Domain (BLL)
2. Repositories (DAO)
3. Services (coordinator of BLL and DAO)
4. UI

Uncle Bob gives talks on Clean Architecture.

Because you actually want to improve your design, I strongly advise you to listen to his talk.

He advocated how the Single Responsibility Principle still applies not just to a class or method, but also to how we design our architecture.

Specifically, you should strive to group things together that typically change together and pull things that change for different reasons.

Consider this architecture:

- Core
   Dependencies
   class1
   class2
   .
   .
   .

- Stories
 - CreateUser
    Dependencies
    View
    ViewModel
    Repository
    Tests

 -  ShareStatusUpdate
    Dependencies
    View
    ViewModel
    Repository
    Tests

The above architecture engages a developer to immediately comprehend the architecture’s intent based on the functionality that the architecture clearly exposes.

Notice how this architecture does not obscure the functionality of the system through the use of “Controllers” “Models”, “DAL” but instead exposes the user stories it supports in clear detail such as CreateUser and ShareStatusUpdate.

Hence, the architecture should convey the design of a system easily without the user having to dig through folders (i.e. Controller, Model, DAL) to understand the intended functionality. “Controllers”, “Models” and “DAL” are low-level details of an architecture and not “the architecture” itself.