Lots to parse here. TLDR; Focus on what's important (maintainable code), rather than jumping to an assumed/unverified root cause (lack of documentation).
First, and perhaps most important, is your perspective. From the tone of your Question, it appears to me as if you're not only unfamiliar with Scrum, but disparaging of it. If you come at a Scrum project with the mentality of "How can I work around this nasty Scrum thing?", then you will fail. Do not be overly concerned with what Scrum doesn't do, and instead focus on learning how Scrum is supposed to work.
From the Agile Manifesto:
Working software over comprehensive documentation
This means, essentially, two things. First, that documentation is important (more on that below). Second, that working software is more important.
You point out the lack of a Software Requirement Specification or Detailed Design. To me, this lack is a good thing. Expending too much effort into upfront design has two side-effects. Firstly, it puts more time and effort into design and documentation instead of writing code. Secondly, it locks the Team into a particular mindset, which in nearly all cases will either be wrong, will become wrong as requirements change, or both - thereby making the Team less able to respond to change and update their code. They will always, in the back of their minds, be trying to 'stick to the plan'. Both of these will harm the Team's ability to create working software - which, again, as per the Agile Manifesto, is more important than documentation.
Regarding the code-first approach (versus a database-first approach, or an approach where both are designed separately and then connected somehow), that is a completely separate Question that is out of scope of PMSE. Suffice it to say, there are, at the least, many people who consider it to be a valid approach.
They only create some user stories
which seems to me as if either you don't understand the purpose of User Stories, or else your Team is not using them correctly. User Stories are a form of (living) documentation. Years later, when trying to figure out why a piece of code was written, you should be able to go from the code to its corresponding User Story, and see it there. If you cannot, then that is an issue that needs to be addressed.
One approach that I've seen work well is to:
- Save all User Stories, each with a unique key for easy future lookup.
- Include that unique key on the commit message of any code relating to that User Story.
How to maintain the code later?
The best way to be able to maintain code in the future is to write maintainable code. That seems like a tautology, but there are other approaches (such as comprehensive documentation) that some (in my opinion, erroneously) consider to be most important.
There are various ways to accomplish this - code review, pair programming, better hiring, training and culture to obtain/raise/retain better programmers, technological assistance (such as a StyleCop of some kind).
In the end, make sure you're focusing on the right problems. Rather than focusing on Scrum's lack of documentation, instead focus on the goals of Scrum and Agile. These include improving quality of individuals and their interactions, writing working software, improving customer collaboration, responding to change, as well as the various goals of Scrum - see the Scrum Guide. If these goals are not being met, focus on that, including first trying to find the cause, rather than automatically assuming you know the cause (e.g. lack of documentation). If you have a goal that does not line up with the goals of Agile and Scrum, first ask yourself the the project really needs it. In some cases, it does (and therefore Agile/Scrum are unsuitable for that project). In many cases, it does not.