Is it justified to increase and duplicate code to break up logical processes?

Question

Software design

Good day!
I am writing an application to work with parcels.
Initially, it was planned to use the statuses of parcels to track its status and, depending on the current status of the parcel, allow certain actions on it.
But I decided to abandon this method, since when the status configuration changes, the logic of the application behavior also changes and confusion and violation of the business process logic may occur.
It was decided to track the status of the parcel without using statuses, . For example: there are 3 tables in the database, Shipments, Parcels and Returns. In order to find parcels that are ready for shipment but not yet shipped, just look in the Shipments table and find all parcels that do not have a shipment number or shipment date assigned, the same is true with Returns.
In order to find parcels received at the warehouse and ready for delivery to the client, it is necessary to extract from the table Parcels, data on parcels that have a shipment number and no sign of sale and no return number. Parcel statuses are still there, but now they are used to store the history, and in case of violation of the status configuration, the maximum that can happen is to write an incorrect status to the history, and what should have happened to the parcel will happen.
And now to the heart of the matter.
Having decided to move from statuses to processes, I intentionally increased the code and in some places there are even similar database queries, in addition, when using statuses, I had to change the data in only one table, and now in two, do you think such changes?
In fact, no one except me should have climbed into the status configuration, but I was afraid that after some time I or someone would get into the code and might change something in the status configuration, thus violating the logic of the application. Now, in order to break something, you need to work hard and change the code of a particular process.

Answer 1

Perhaps it is necessary to proceed from whether the processes will change. If they are, then your version is more difficult to modify. If not, then you need to identify extension points in your code and understand how difficult it will be to make changes without breaking code that already works. How can you scale your solution if the load increases greatly. In addition, if it is required to change several tables synchronously in a process, then in order to ensure data integrity, such changes must be made atomically, i.e. in a transaction.
And adding a transaction can lead to locks and deadlocks during multi-user work, unless, of course, the number of operations is large. In general, to understand the pros and cons, you need to understand exactly how your application may need to be finalized and estimate the load profile.