Sometimes where do you begin is always the hardest part. I remember my c# days working in visual studio and you would hit the various options of code first Vs domain first.

For me my mind actually works best working at the data level. I like to list out the conceptual blocks of data that will be used within my application. Some of these might be stored in memory and some might be stored in a database for long term. At this point it's conceptual so I don't need to worry too much about those things.

Once I have my conceptual model built I can start to group things and pick out the objects and classes. It is not until then that I start to code. This is conversely different to writing your UI first or your code and then discovering your data needs as you go along. Both ways are iterative but I do think this distinction is purely down to the project and also the way that the coder is wired. I find it really tough to mock up screens, but give me a data model and I can visualise everything I need. It's probably why I enjoy taking manual business processes and automating them in some way. Seeing paper or excel forms people are filling out give a clear indication of their data needs and from here it is a case of building that out in a way that means the minimum of input for the greatest gains.

As has been said, new projects are definitely a divide and conquer exercise. But remember you can split up a project both horizontally (modules, classes, folders) and vertically (front end, back end, storage). I think mixing across both the vertical and horizontal allows you to chew off pieces of code and the overall problem becomes much smaller.

Start out high level, don't be scared to learn and iterate. Fail fast and learn.