I have a domain that deals specifically with creating, editing and producing word documents containing business related data. I also have a library that wraps the OpenXML SDK (.net) and offers a high-level API for a WordDocument.
My use case is that the user can create such a word document (via an according WPF UI), feed it with some custom business related data (e.g. insert images & text) and then finally save the changes and destroy the instance. So I need to keep track of an in memory instance of the word document to handle all that.
Now following the DDD way, usually I wouldn't want any technology to leak into my domain model but then I need to have behavior on my Document aggregate (like Open(), Save(), FeedData() etc.) that of course would need to be applied to such a word instance.
Without referencing that library in my domain where should this Document instance reside? Should my corresponding application service handle such a member instance? But that seems strange because usually my services are stateless and only orchestrate the behavior of my entities.
I have the strong urge to see the required technology as part of my domain and when talking to our domain experts, we are actually speaking of "word documents", so it's part of the ubiquitious language. I am a bit confused if my assumption leads me the wrong way here.
I guess my question is if technology can be part of the domain model if the domain (and its language) includes the technology?
Can technology be part of the domain model if the domain includes the technology?
The DDD police are not going to come after you if you don't do what they expect.
There is an important boundary in DDD between the domain model (which is the expression of the business logic) and the application (which coordinates between the business logic and the plumbing that we need to make things work in the digital world).
The motivations for the separation: the domain logic is a separate concern from the application logic - we should be able to "lift and shift" the domain code from one application to another (from a custom desktop app to a web site, for example); the application code tends to change for different reasons than the domain code.
Furthermore, when working in the domain logic, it is helpful to the process of programming to remove all of the application concerns from context - within our domain code, we should be concentrating on "what happens in the business when the customer places an order", without being distracted by a bunch of application concerns like "how do I fetch their order history from the database?"
An important question about your document - is it data on the outside? or data on the inside?
If it is data on the outside - meaning that somebody outside of your domain model is responsible for the contents (example: human authors are writing the document), then your domain model probably doesn't care about the document at all.
If it is data on the inside - meaning that your domain model is responsible for the contents of the document, then your model will know something things about it. Not necessarily load/save -- your model probably doesn't care very much about the persistence solution that you use, but making changes to the document model itself, sure.
You can probably draw a close analogy to email - the domain model may know what the contents of the email should be, and the address of the recipients, and the time that the mail should be scheduled, but the domain model probably doesn't include an SMTP client (that would normally be an application or infrastructure concern).