Program architecturing steps

Question

What is the first step in program architecture, Database or Class structure architecting?

Answer 1

Gathering the requirements. For the architecture, the Non Functional Requirements are often more important then the functional ones.

Answer 2

I would say "whathever you are confortable with".

If tou are using a relational model you will have to bridge the gap with the OO world anyway (using ORM for example).

I usually start working with the database, but the overall class diagram for the system could improve the database design phase greatly.

The methodology is a very important thing to consider as well. An agile approach and TDD would handle the intense changes in the schema better, so you can go back and add/remove tables, fields (or classes) with ease, and use both the strategies whenever you feel like it.

Answer 3

For the two options that you have... I'd go first with Class structure then Database...

Usually Class structure will represent business object that should be accommodated by the database, nonetheless that's a general case, there's a lot of exceptions to that.

• Usually for most "business centered" applications think about real world business objects, then its abstraction as classes the its conceptualization as database collection of tables and relations. If you're class design is relatively ok classes and database tables shouldn't differ that much.
• If you have an "information centered problem" as in expert system or data mining, then go for database first.

Answer 4

Database or (persistent) classes are just a small part of the software...

Usually, people choose the technology they know better (SQL or code), and define the other one according to this.

Using an ORM has to be considered.

Answer 5

Do both at the same time, step by step. Don't try to get either "100% complete" before taking a look at the other.

The reason is that there is no 1:1 mapping between objects and databases. For example, it's very simple to create object trees. Most ORM frameworks have serious issues when it comes to map that to a database. Also, it's often impossible to retrofit transaction handling to an existing app without rewriting all the code.

Starting with a great DB model can leave you in a situation where it's not clear how you could represent that with an object model. DB issues will leak into your object model.

This is why you must evolve both parts of your app at the same time, learning as you add features, protecting your assumptions with automated tests.