One approach linked to OOP is especially problematic: Domain Driven Design. It is very attractive at first, because it gives you the holy grail of code architecture – separation of concerns. It says that you start designing and programming from domain logic and ignore persistence and user interface until you work out your problem domain. Support for persistence and user interface is added later, almost as an external system, so that you can replace them without changing anything in domain logic.

Where’s the catch? If you really design your domain logic first, ignoring everything else, you’ll end up with program that doesn’t work in any of the environments hostile to OO (stateless, distributed, persistent, parallel, asynchronus, relational, transactional) and I can’t remember any domain worth mentioning that doesn’t need to work in this environments.

Of course, no approach will give you this functionality out of the box and domain driven is no different. What’s dangerous in domain driven is that once you start adding code required for persistence or transactions, your core design must change. And it changes so much that new concept doesn’t have any resemblance with original one. For example, unit of work is not needed in any domain. But you have to add it for persistence to work. And when you do, you must change every object to work with it and every function to register changes of state.

Generaly, building a part of a system ignoring other parts just doesn’t seem like a good idea.