Not a definitive response, but should point you in the right way
Repository and UOW would have been handled by the framework if you intended to utilize ORM.
You can start with the following layers: 1) UI, 2) Service Agent, 3) Service Layer, 4) Domain Layer, and 5) Repository.
Customer to Service The service layer is not required if there is just going to be one client using the service. May be Facade layer, which will operate in the same process as the user interface, is sufficient. If it becomes necessary to serve numerous client applications, it can be refactored into a separate service with comparatively little work. To the service agent, abstract all service calls (Proxy). Agent is the sole conduit for communication between the user interface and the service.
You might want to think about utilizing a viewmodel for each screen if you're using anything like the server side mvc framework (for instance, asp.net mvc). The majority of screens combine information from many domain models (Order details, shipping details, and customer details are all displayed on the same screen), hence the view model will do the same. Look at the (.net) auto mapper in this situation to map DTO (Data from Service) and view models, or create your own lightweight mapper. You don't need to explicitly create the view model if you want to use client side MVC for UI (such as Angular). Whatever the service produces will serve as a basis for your UI.
backend service The domain model's appropriate methods will be called from the service/facade layer. Design POCO from the domain model call repository for all CRUD operations. Repository may use ORM internally. You may need to write some general code to map data from a database or other data store to a domain model if you are not using ORM for whatever reason.
All classes in the domain layer, repository, and service layer should have defined class interfaces (anyway framework will force you to use interfaces for services). Don't forget to develop coarse-grained interfaces for services and facades; otherwise, there will be too many calls between the user interface and services.
Make a separate project for each layer, choose a use case with an average level of complexity, and begin building it from beginning to end while utilizing all the levels, entity kinds (view models, dto, domain models), and mapper (Viewmodel-dto, dto-domain models). As interfaces belong to the customer, I would advise keeping all interfaces in a separate project from projects for concrete classes. This will guarantee that the client won't be directly dependent on the actual implementation project. To inject dependencies into an IOC container's client, identify it. Example: Use DI to inject the domain model into the service layer classes. Set up DI so that concrete implementation is injected into all tiers (Service would use DI to get domain models, domain model would use DI to get repository). Using DI will force you to write code against interfaces, which is advantageous. Refactoring interface, classes, methods, and structure is crucial to ensure that the overall structure is satisfactory because the high level design you apply for the initial use case will essentially serve as a template for all subsequent uses.
After finishing one use case, you and your team will put more work into studying, designing, and discussing the domain model (Read Eric Evans' article on domain driven design, the author/creator of domain driven design). It might be difficult to know where to begin and how to begin when there are so many factors to consider. As I previously mentioned, begin with a project for each layer, add or remove as you rework, and refactor frequently.
The project must be somewhat complex, in my opinion.