I have a small side-project of about 3,000 sloc. I'm experimenting with building a DDD-like domain model into it, so I have more experience with this style for work. The project is centered around reading and writing a specific file format which has not changed for 20+ years. And I'd like others reading my code to be able to easily pick out parts of my encoding/decoding logic.
As I understand, persistence-ignorance is the major concept of DDD. Yet I'm having trouble picking out what persistence I'm supposed to be ignorant of. If my encoding/decoding logic is so central to the premise of the application that it has to be in the domain layer, what is left of the infrastructure layer?
1 Answer 1
I disagree "persistence-ignorance is the major concept of DDD". The major concept is to focus on the domain (hence the name). Since storage/persistence is not the core domain of most business application, persistence-ignorance is a common way of abstracting away irrelevant details for the core domain. But this does not apply to your case.
If the main purpose of the application is to read and write data in a specific format, then this is the domain of your application, and exactly what you should focus on.
-
1The trick then is to see to it that storage/persistence remains the domain of your application. Things will go bad in a hurry if you start adding other concerns.candied_orange– candied_orange2017年05月03日 15:19:49 +00:00Commented May 3, 2017 at 15:19
Explore related questions
See similar questions with these tags.