Domain services and application services for graphics-based applications

Question

I am trying to wrap my head around the domain driven design concept of the service layer, both application services and domain services. Virtually all of the examples I've come across have to do with CRUD applications with databases. I'm having trouble understanding how these concepts map to graphical applications like the example application I've chosen for this question, a clone of Microsoft Paint developed in .NET/C#.

I read the basic concept of a service layer in DDD and an expanded explanation. I have chosen the following application layers:

Infrastructure (cross-cutting)

• Logging

Data (filesystem)

• BitmapImage, PngImage, etc.

Domain

• Canvas, Image, Selection, Shape, Brush, etc.

Application

Presentation (local client WPF)

• Views
• ViewModels

One use case I'm trying to design is the user drawing a rectangle on the canvas. From what I've read, since the use case requires the cooperation of several domain objects a domain service, DrawingService, would make sense.

Another use case would be the user loading a file to be displayed. Again, from what I've read, since this use case is a command and a workflow, an application service, FileLoadingService, would make sense.

As Martin Fowler describes, I believe Microsoft Paint is complex enough to warrant a service subsystem, here based on thematic behaviors. However, as the application grows, the service layers could be refactored to fall into partitions of the domain model, e.g. CanvasService, SelectionService, etc. Would than then necessitate another layer of abstraction, perhaps an application facade, now that multiple services must cooperate?

Update 1:

Initial comments suggest DDD architecture is not a good fit for a drawing application. Any suggestions for an alternative?

Answer 1

imho a drawing application is not a very good fit for DDD. It would use something else