Without knowing what you are asking exactly, there are a ton of ways to structure a large project.

One of my favorites is: Pick some challenging (but not too challenging) use-case that intersects an interesting subset of the core requirements. Decide on ONE design principle you want to follow (highly testable, clear separation of concerns, pluggable sources/endpoints, whatever) and then build the crappiest/minimal version that does those two things (handles the main use-case and strictly adheres to your design principle) while being totally crappy in every other way (i.e. bad UI, brute-force algorithms, whatever). As you design/build this "slice"/MVP of functionality, keep notes about out-of-scope parts you can't/won't touch according to the rules above. Those will become seeds for the rest later.

This method yields a lot of advantages: 1) It provides a way to get started without analysis-paralysis, 2) it results in proof-of-concept, perhaps a demo for what you are going to eventually build, 2) You think through a lot but don't build so much or get lost in details you won't build, 3) If you hate the MVP, you can throw it away and build it again the right way (which will be better, as a result).

For a really big project, just iterate on the above by picking more slices/use-cases. You might have to refactor/redesign as you go but pretty quickly you'll have built up enough scaffolding that the rest of the project will flow easily or be delegated easily.