During modeling a business logic we have often a problem with properly highlighting a relevant future action. I mean relevant from a domain point of view. The most popular solution will be using a CLI command which will be executed by cron at a specific time. I think that this solution often hides a lot of business logic in an inappropriate place. Perhaps, there is a better way?
Nowadays, a concept like DDD is widely known and used by many programmers. Curious programmers read a lot about those practices in books written by Evans or Vernon or maybe have knowledge from conferences or blogs. As I saw many times, people are trying to be too much strict with these practices. Trying to make a domain completely clean is of course highly desired, but if you have a not very complex domain, and to have a completely clean domain you need to highly complicate the code around it (probably Infrastructure’s code) something is wrong, don’t you think? So you need to think about the return on investment. Is it worth having more work to do, and complex infrastructure code to just make your domain completely clean? In most cases probably it isn’t at all, only in projects with a highly complicated domain it will be necessary to define a core domain, and then perhaps making this core domain completely clean will make sense. However, not every place in your project will be perfect, you should invest your time only in the most important places. So in this article, I would like to write about using ORMs when approaching DDD which are often hated by many people.