I have a somewhat radical idea of this “version 2”. It’s quite simply – if you are successful enough, you’ll do a better version 2. It’s really an extension of “rome wasn’t built in a day”.
When you’re doing your own little startup projects, sometimes you get caught in a “I must make this super generic so that I can <do something here>”. You may even throw in some layers and more layers, just incase you have the crazy idea of dropping traditional database for something more NO-SQLy.
But lets have a long hard look at that very example. Layers of Layers. So here is a simple system: Webservice needs to access data. Any sane architect would say something like: Webservice uses another service later which then hits a dao which then does the DB queries. Webservice | Service | DAO | Database. This lets pullout that database without effecting the Service and webservice, or lets you do logic changes without redeploying webservices because you might be on a large distributed elastic type hosting…
Now, I can say that I spend A LOT of my time converting SQL queries to entities to vos all through a layer of a “service”. It’s a huge waste of time. It takes far to long to get a list of ids from the database to the front end.
And this is where my “version 2” comes in. When you’re starting your own little project with big ideas – dont focus on “great large scale design”. You don’t have the time. This rings true when you don’t even know if your idea will be successful or not. So how I’d do “version 1” is something like: Webservice | Dao | DB with no entities and just vos.
“But what happens if you find that you need to throw out the DB, the webservice and DB are heavily linked to vos and it’ll be a disaster”. Well.. yes. But when you are that successful, you’ll have a team that can write “version 2”. Besides, it gives you a great time/place to make mistakes and understand first hand why “no-sql” is cool rather than just being told it’s cool.
Books, people and websites go on about “good scalable design”. This is only really useful to large companies that are already successful – who can throw resources at this problem. As a single person, or a small team, it just gets in the way and time to live is pretty much your secret weapon against slow mega giant companies.