We’re working on a freaky big service-oriented multilayered application, that has to be designed from scratch.
Now we need to start programming, and try to assemble the first bricks.
The question is where to start?
Some are suggesting that we should start by designing the persistent data models, which would provide a clearer view. Is this a good approach?
Edit for Suirtimed
There is not much an Agile culture here.
This is an SOA style project, using WCF, SQL Server, Entity Framework (using POCO generator for Domain Objects), ASP MVC and Workflow Foundation.
We are a team composed of 4 developpers; reasonably skilled (but not experts).
The broad overall approach I always try to follow is to begin by designing the domain models. This is your “ubiquitous language” which will define business objects and concepts, contain business logic (later on, when you have it), and generally be the common language used throughout the various parts of the system.
The idea is that it should be understood (or at least understandable) by everyone involved. For example, some manager in some other department isn’t necessarily going to understand relational databases or anything about persisting his department’s data therein. But he does understand the business process of his department. Their vernacular, their concepts, their interactions, etc. The ubiquitous language is the common ground the groups share.
During this process, you should keep your dependencies in the front of your mind. The biggest one is usually data persistence. There’s sort of a golden dream that domain models be persistence-ignorant or dependency-ignorant in general, and for the purpose of separation of concerns that’s a good thing. However, true dependency ignorance can paint you into a corner. You may run into some serious performance issues or architectural issues that require a lot of re-design later on.
So break from the domain modeling occasionally to think about persistence (and other external dependencies, such as external services that need to be used or third party applications that need to be integrated). As you model the domain, make sure that model still works properly with everything it needs to. You may have to compromise a little on the ubiquitous language here and there in order to accommodate the limitations of a dependency.
Basically, design the domain model before you design the database. But don’t forget about the database during that process.