Lately I watched few presentations about DDD and software architecture. What hits me after that is that we are no longer developing applications. We’re developing systems. Ask yourself when was last time when you created app which worked alone without other software?
When we are at home, in our application we don’t really care about how data are moved from one object to another. Most of the time we are type hinting for specific class, sometimes is a bit better, when we are targeting interface of specific class. Both ways it’s working fine inside application. What happens when we want to reuse component in other project or move it to different machine? Nothing scary, we create some DTOs, some serializations and we’re done. But why not use this generic date structures in first place? It’s slower? Like DTOs and serialization is fast. It’s additional work? Serialization don’t need code, right?
Another thing is possibility to reuse component in other application. That’s the idea behind Bundle system in Symfony 2. But when I see code it’s more about nicer look and feel than reusability. What I want to say that OOP in SOA is not always the best answer. When we come to border of application we can’t say to outside world that we we are using Symfony\Component\Security\User class. We are sending some raw data. Nobody cares about our internal naming.
Quick example from my current side project. I need some rating mechanism and you can say let’s create related table for “votes” and we can call this everywhere we use base entity. Nice? Easy? Yes. Reusable? Nope. I think better solution is when I have identity of object (for example class name and ID or simply some GUID) and I’m counting votes without thinking what for. It’s fast with proper indexes. It’s reusable for many types, not only for this one “related” so I can simply use this component as a vendor. Can I move it easy somewhere else? Yes. What I need are two values – object id and vote as number. No DTOs, no hacks to make it work with related table and foreign keys in main database.
So stop thinking that you are alone there. You are working on system, not only your piece of code. So be lazy, don’t be attached so much to objects and try to think more with data than how this data is named. You are (and were) System Developer.