[Atixx]

> Developing the SQL schema backing that UI is arguably something that is 100% deterministic and can have mathematical proofs established which prove its correctness one way or another.

Maybe I'm misinterpreting your point here, but the way you create the different models, compose the modules which will use them and represent the abstract entities and processes that execute when that UI is interacted with can be done in many ways, both well and very badly, depending on the measurements you take to evaluate it. All the different terms to consider 'clean', 'maintainable', 'readable', etc. code, I consider to also be somewhat abstract to define in an art-type of way.

The reason I mention this is that the 'visual design' of the UI is not so much a software work as much as a UI/UX designer work. Bringing that design to life in an application using actual code and not a design tool is where the same principles I mentioned above come into play, even if the actual 'visual design' was completed by a different person which might not code, or the same dev.

[bob1029]

I would argue that there is a very specific form of normalization that any problem domain should be modeled in - 3NF or BCNF. This is a universal idea because of how it allows for relational algebra to easily produce any higher-order functions over the dataset. Poorly-normalized data is where all of the code & SQL spaghetti originates. These forms of normalization can be specifically tested for and validated.

If you get a super clean domain model in 3NF, you can be assured that writing business logic on top of this will be a breeze. Getting relationships between domain types incorrect, or having facts on the wrong types, is how you get a vicious cycle complexity layering on top of itself as you try to compensate for bad foundations.

One thing that burns a lot of developers is the need for circular dependencies. You cannot say that circular dependencies are disallowed when trying to model the real world. An example in banking would be Accounts can have many Customers related to them, and Customers can have many Accounts related to them. Attempting to "choose sides" on this is folly. The most correct path is to create 3 collections - Customers, Accounts, and AccountCustomers (or CustomerAccounts). Getting this one thing correct can save you years of developer hours on the bigger projects.

If you are using something like .NET, you can abuse LINQ to produce any arbitrary projection you desire in a few lines of code. If you want your business people to have a hand, you can expose SQL as a scripting language against your properly-modeled domain. There are so many good reasons to slow down and pay attention to what you are calling things (and what boxes you put the things in).

To put it more briefly - The argument I am essentially trying to make above is that there is actually one truly correct way to model a specific problem domain and you can test for many degrees of that correctness. I will admit it is never absolute, but I feel it gets damn close if you are thorough in applying single responsibility principle to the logical business facts.

[urthor]

Developing the schema is a not a science.

Implementating BCNF is a science.

Choosing whether to use a normalised relational database, a star schema, or a non relational eventually consistent database, that's design.