Part of the problem comes from having a DAO that mimics your use cases when writing data. That is, adding a new Pipe is a business concern. Here, the author has

Part of the problem comes from having a DAO that mimics your use cases when writing data. That is, adding a new Pipe is a business concern. Here, the author has turned it into a data concern. A business concern should be modeled in the domain layer and persisted through the data access layer. By the time we write to the database, there should be no thought involved. The work has been done and we want to record it. How we do that is purely up to our technical requirements. Several years ago, I wrote an application using the repository pattern and there were repositories everywhere. But they seemed like a step up from the unstructured chaos of the DAO. It was a bigger mess when all was said and done. Having struggled through the same issues as the author, I can say that after having learned and applied and DDD, CQRS, and Event Sourcing, I don't see the problem anymore. My concerns are one or more levels above "how do I write to or read from the database?". The database becomes a technical implementation detail and not the cause of crisis in architecting a system. In the past few months, I've used EF as an ORM, EF using just stored procedures, and Dapper, both through a DAO interface. All of these solutions worked and were easy to implement because I was simply recording changes to data, not putting the data at the heart of my logic.