How does the top-level directory structure reveal the purpose of the application?

Question

Robert S. Martin, in one of his talks about clean architecture, openly criticizes a fairly standard way of doing things these days. Robert C. Martin - Clean Architecture and Design

What I understand as a standard way looks something like this:

 solution - UI project - Models - Views - Controllers - Assets - Logic project - Data project 

Martin here says that an application should immediately reveal its purpose when you look at its top-level structure ... I wonder if anyone can provide an example of such a directory structure, for example, when using the MVVM template as a delivery mechanism? How can you structure your application in the way that Martin describes?

Answer 1

From what I see in your example, I can only assume that this is an ASP.NET MVC application, we need to take a look at the Logic or Data projects to understand what this application is about.

In most cases, people organize their entire directory structure based on the technology or framework used. This comes from how the default project template is created (without knowing anything about what your application should do, they really cannot do much more than that for us).

Now, what Robert C. Martin tells us is that our top-level directory structure should reflect what the application does, and not how it is built. I am not sure that it is a good idea to do this at the solution level. However, I always recommend that the Domain project is that we can apply the principles of Domain Driver Design .

If in such a domain project you see the following folders at the root level:

 Clients Orders Billing Shipping Promotions ... 

You can guess that this is a kind of e-commerce application. You will need to go even deeper in the directory structure if the folders you would find are similar to Models , DTOs or Exceptions .

I don’t like having too many projects in my solution (up to 10, if possible), so I don’t go and create one project for one domain object of my system. This is why I believe that the root level of projects, not solutions, was that we should focus on determining what the application does.

Answer 2

He does not speak of a structure that gives its purpose as such. He said there should be use cases at the top level so you can quickly see what he is doing and where code changes are needed. I don't think he talked about folder names at all. Additional Information.