How do applications that don't involve user interaction take advantage of domain driven design?

Question

I'm pretty new to domain driven design, but I'm interested in its benefits. Currently, I'm working on a C# application that will run on a one-off basis to import data from many different spreadsheets (over 100) into a cloud-based system. There is no UI, and there is no user interaction. There's simply a target folder the program reads from until it's read all spreadsheets and then it stops. The application is essentially reading domain objects from one persistence type (spreadsheets) and using the use cases in the application layer to save them to another persistence type (cloud system).

I describe all my objects in the domain layer, lay out interactions with the cloud system in the persistence layer, and specify the queries and commands in the application layer. Currently, I don't have a presentation layer; do I need one in an application with no UI? Additionally, where should the actual code that reads from the spreadsheets go? I can't figure out if I need an infrastructure layer, a presentation layer, or if I should just put this in the application or persistence layers.

Answer 1

Greg Young, in 2012, proposed this litmus test for DDD

What level of our level of competitive advantage comes from this?

At a guess, a process for uploading spreadsheet data into the cloud probably isn't the way your company distinguishes itself from its competitors. In that case, it would be an over investment of resources to go too crazy on this project.

Simple projects can make good sandboxes for practicing.

Currently, I don't have a presentation layer; do I need one in an application with no UI?

No. That said, speaking from experience you may find yourself wanting a UI for monitoring the process itself.

I can't figure out if I need an infrastructure layer, a presentation layer, or if I should just put this in the application or persistence layers.

Udi Dahan would advise you to think in "components", rather than "layers".

Additionally, where should the actual code that reads from the spreadsheets go?

A common design is that File I/O, and everything that gets contaminated by it in order to create an in memory representation goes in one place, a pure model that understands how to manipulate in memory representations goes in another, and there's a small bit of glue to line them up.