You are no longer application developer

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?

It’s not obvious, because we are forced to use some kind of libraries for databases, AJAX request etc. Now we often have 3 applications – frontend based on some JavaScript MV* framework, JSON API in PHP, Ruby or something similar and some database MySQL, Mongo, whatever. My point is we don’t care about how this thing communicate with each other. We simply use it because it’s the convention for them and we don’t think about that they can fail or be replaced or moved. Same thing happens inside this PHP/Ruby layer. In JavaScript layer is a bit better when people are using LocalStorage, but it’s not my area of expertise.

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.

Multiple entities in one Symfony 2 form

Case: User belongs to Account entity and in registration form I want to create Account for him.

First I have simple registration form from FOSUserBundle. To extend it you have to create new form type which contains fields from other entity. In my example I have only name required to create new Account.
Continue reading “Multiple entities in one Symfony 2 form”

Truncate filter in Symfony 2

Fabien Potencier created very useful filter for truncating strings to given number of chars. It’s included in Symfony Standard Edition, but not enabled by default. To fix this place this in any of your service-config files. Continue reading “Truncate filter in Symfony 2”