When do domain concepts become application constructs?

Question

I recently posted a question regarding recovering a DDD architecture that became an anemic domain model into a multitier architecture and this question is a follow-on of sorts.

My question is when do domain concepts become application constructs.

My application is a local client C# 4/WPF with the following architecture:

Presentation Layer

• Views
• ViewModels

Business Layer

• ???

Domain Layer

• Classes that take the POCOs with primitive types and create domain concepts (e.g. image, layer, etc)
• Sanity checks values (e.g. image width > 0)
• Interfaces for DTOs
• Interface for a repository that abstracts the filesystem

Data Access Layer

• Classes that parse the proprietary binary files into POCOs with primitive types by explicit knowledge of the file format
• Implementation of domain DTOs
• Implementation of domain repository class

Local Filesystem

• Proprietary binary files

When does the MyImageType domain class with Int32 width, height, and Int32[] pixels become a System.Windows.Media.ImageDrawing? If I put it in the domain layer, it seems like implemenation details are being leaked (what if I didn't want to use WPF?). If I put it in the presentation layer, it seems like it's doing too much. If I create a business layer, it seems like it would be doing too little since there are few "rules" given the CRUD nature of the application.

I think all of my reading has lead to analysis paralysis, so I thought fresh eyes might lend some perspective.

Update 1:

To clarify that the application is not a strictly CRUD, the domain layer would also contain signal processing functions and image transform settings. The signal processing functions must be applied on the raw pixel values directly from the DAL, while the image transform settings are stored with the domain objects to be applied by WPF as part of the presentation.

Answer 1

Sounds to me DDD may a bit overkill for your type of application. Images, layers and such sounds like you'd have mostly to do with presentation logic. I would not worry too much about the anemic part, if there is little business logic, it is as it is.

For the domain layer I would stick to names and terms your users would use. Does your user know what a MyImageType is and what it's supposed to do? No? Then it doesn't need to be part of the domain model.

It may help to just tell yourself you are not doing DDD, but just borrowing some of it's ideas and patterns.

If you are stuck in analysis try to focus on things you could do now without shutting too many doors. Postpone decisions as much as possible. Go for simple solutions that you can expand. Allow yourself some room to make mistakes. First make it work, then make it pretty.