How to document form fields (including validation, logic), api, database?

Question

Documentation

Hello,
We started developing a web application (SPA) in the enterprise segment. The application contains a bunch of forms, grids, and so on. All these fields are connected by curly logic.
For now, fields are described in excel, API is described in Api-blueprint format in .md files. The database is not described at all, but it is clear that you can reverse engineering and see the connections.
Tell me if there is any software or methodology, best practices, how form fields, api, database fields are documented and that it would be all in one place and refer to each other. Eg. by gender in the database, find a field in the API and / or a field in the form and vice versa. Again, there is no clear mapping, there can be api fields without form fields and fields in the database, as well as the reverse, thus.
maybe a form field != api field != database field.
I tried to write simply in text (tables) in the TK, well, it turns out some kind of mess, all this in different places. Difficult to maintain, eg. when the name in the form changes, it is necessary to find not to forget and find . fields in the database, API and change them.
With the description of validation and logic, too, somehow everything is smeared out. Perhaps hands grow like this :) but I hope that there are solutions, I just don’t know about them.
Thank you.

Answer 1

All these fields are connected by curly logic.
Perhaps hands grow like this

Smiling)))
Go from role:
Role/object in the system (or class) - it will be a noun => entity in the database (product, user, article/publication, comment, etc.).
Role properties (or class object properties) is an adjective => entity properties in the database (color, weight, etc.).
A manipulator (possible role/object actions; class object methods) is a verb => Activity table of an entity in the DB.
Then - do the usual documentation of these classes (it's also an API).
Everything that you have in the form fields at different points in time is a special case of the interaction of class objects and / or other auxiliary blocks.
Therefore, each form is documented in the form of a list of parameters indicating the type of the field and the class with the property for each form field.
But the transitions between forms are already drawn up as a business process diagram.

Answer 2

Document with tests
AND make models as thick as possible

Answer 3

You need to:
1. Look here: schemaspy.sourceforge.net
2. Then look here: dba.stackexchange.com/questions/515/how-do-you-doc...