[Project design] Consider abstracting business logic

I don't want to clear any good theoretical guidance at present, which makes the project structure a little bit ambiguous.
Currently, the project code is very simple, but the coupling is too large. It can be said that the interface prevails. For example, view all contracts. Our operation is to directly use ado.net to communicate with the database. After returning all the contracts, bind the dataset to the DataGrid. The link is provided to allow the user to view the details of a contract.
In this way, it is instinct, direct, and effective. However, the premise is that the customer's requirements are stable. As for its disadvantages, I think anyone who has practical experience knows it. I will not talk about it here.
Today's focus is not on the basic way of thinking. My problem is how to effectively change this approach. In other words, which method should be used to replace her.
After a lot of consideration, I still think it is very impractical to apply ORM to seemingly large architectures (I have considered Orm. However, I feel that ORM is not suitable for projects with unstable requirements. I am not very familiar with Orm, let alone practical experience ).
In addition, for small projects, the construction period is short and the customer's requirements are vague. All factors determine that we need to find things that do not change and abstract them out.
When some seemingly changing entities are abstracted, we can move the center from the interface to more important business logic. I feel that after doing so, at least the layers will be clearer. The coupling degree will also be reduced, and subsequent maintenance work will become simpler.
The general discussion is generally meaningless. Therefore, we plan to re-analyze the projects we have already done and calculate some practical principles.