How to structure separate projects in a single solution? i.e project.Domain etc in C#

Question

So this is a very beginner question, so please do be patient with me: But I am building a little practice project and what I am struggling to understand is the overall structure of the solution, in terms of breaking projects up. I assume this is for easily readability and maintainability and as I have never worked like that before I have a few questions.

So for example sake, I am building a payment app where people transfer money to eachother ("pretend" money) there will be a basic front end using razor pages and an api solution that captures all info from the database and exports as json.

So far I've structured my project thusfar:

project.Domain (this contains all the actual logic, such as the core models and controllers, and code to transfer money from one account to another etc )

project.Presentation(this will be where all the razor pages live, so in effect the data from Domain is passed into here and printed to the page)

project.API(this gather app info from the database and export as json. This is restful and will allow for verbs like put, get post etc etc.

Like i said i've never done this before so im trying to use common sense here. Typically what I normally would have done was create a single MVC project and put everythere in there! but I've been learning SOLID and that made me think the code should defo be structured, but also the solution itself too!

would be very grateful for input on this!

Andy

Answer 1

When deciding on how to structure your solution and projects, think about what you are trying to show. In large projects, with multiple devs etc, you want new devs looking at it to be able to get up to speed with what the code base is doing, how it works etc. so they can start contributing and provide value.

So the best thing to do is have a structure that shows what is this application doing. What are the entities it is working on, what is it doing to them. Why does this application exist. (This only really applies when your domain is complex enough to warrant this thought process, so with simple projects I wouldn't worry about it so much.)

I would highly recommend reading up about domain driven design if this is what you want to improve at. Also, there is this amazing video about Interaction Driven Design by Sandro Mancuso. It explains really well the point I am trying to make, I think it will be exactly what you are after.

We want to separate our domain, our business logic, from the presentation logic/delivery mechanism. If you look into Hexagonal architecture as well, it will show you how you want to isolate this and abstract away how you present data, as well as internally, away from the infrastructure.