4 ms·

In my experience, if you have the relational database model fully defined and correct then the rest of the application is pretty much designed. All the screens

In my experience, if you have the relational database model fully defined and correct then the rest of the application is pretty much designed. All the screens and elements you need are obvious.

hire_charts 11y ago
This matches my experience. That's not to say that your application doesn't need to do any work on top of the data. Sometimes you need to interpret the data in different ways for different use cases, and often that means applying transformations at the application layer. But if you find yourself fighting against your own data model, it might be time to consider restructuring the data to better support your use cases.
abraae 11y ago
Indeed, but if you are building in microservices, a new level is introduced. If you can get your service boundaries and APIs fully defined and correct, then the relational database models (underpinning each of those services) just fall from the tree for you. And then as you say the screens and elements are obvious.
- wvenable 11y ago
  Honestly I'd still prefer to go other way -- from the relational database models you get your APIs defined and correct and then the screens and elements are obvious. I find if you start at the database model layer you much less likely to screw up the API design. The database model forces a bit of rigor that you can't get going the other direction.
  - abraae 11y ago
    IMO it's dead easy to create APIs from a database schema, where that schema underpins your monolith and you're opening said monolith up to the outside world, and you don't really care too much what goes on out there. But if you're building a system which is not a monolith, and instead is made of up of, say, 20 services, then putting good boxes around those services and defining the lines that connect them (the APIs) is an essential prereq to designing the databases that sit inside the boxes. (Though really what's happening, as always, is you're doing it all in parallel, just with more emphasis on the higher level stuff).
    - wvenable 11y ago
      I can't really disagree with that. I usually design micro-services the same as do monoliths; it's just the client is different (another service).

In my experience, if you have the relational database model fully defined and correct then the rest of the application is pretty much designed. All the screens and elements you need are obvious.

hire_charts 11y ago

This matches my experience. That's not to say that your application doesn't need to do any work on top of the data. Sometimes you need to interpret the data in different ways for different use cases, and often that means applying transformations at the application layer. But if you find yourself fighting against your own data model, it might be time to consider restructuring the data to better support your use cases.

abraae 11y ago

Indeed, but if you are building in microservices, a new level is introduced. If you can get your service boundaries and APIs fully defined and correct, then the relational database models (underpinning each of those services) just fall from the tree for you. And then as you say the screens and elements are obvious.

wvenable 11y ago
Honestly I'd still prefer to go other way -- from the relational database models you get your APIs defined and correct and then the screens and elements are obvious. I find if you start at the database model layer you much less likely to screw up the API design. The database model forces a bit of rigor that you can't get going the other direction.
- abraae 11y ago
  IMO it's dead easy to create APIs from a database schema, where that schema underpins your monolith and you're opening said monolith up to the outside world, and you don't really care too much what goes on out there. But if you're building a system which is not a monolith, and instead is made of up of, say, 20 services, then putting good boxes around those services and defining the lines that connect them (the APIs) is an essential prereq to designing the databases that sit inside the boxes. (Though really what's happening, as always, is you're doing it all in parallel, just with more emphasis on the higher level stuff).
  - wvenable 11y ago
    I can't really disagree with that. I usually design micro-services the same as do monoliths; it's just the client is different (another service).