This will not be an acceptable answer, but there are some things that can be improved.
Clean Development
Code checkers (were already mentioned) like clint, SonarLint. I use them, and certainly on encountering a new existing project. Consistent and good naming and hundred of things you probably are aware yourself. You are using architectural design: one should not overdesign, but have clear separation of aspects/concerns.
If still messy at times, reconsider the simple MVC pattern in some variation.
When after some time the code becomes messy, for instance coming back for a change request or bug ticket, also do some fast maintenance, cleanup, simplification. Called technical debt. An entire redesign is only a last resort, and only if it simplifies. Detect pragmatical milestones; separate GUI from business logic, already two milestones, achievable separately with mocked data. Per extra feature a milestone.
Be able to communicate, tell what you are doing, what you did. Concisely, short.
That keeps you from being a submarine developer & under pressure.
Consider the requirements, plan them, and when usefull ask feedback.
Test Driven Development
Domain Driven Development is fine, and can be continued. But also do Test Driven Development:
- Separating logic from the view code.
- Having many unit tests.
This will speed up development involving processing, and guarantees code quality. It serves to capture regression errors later. If you rather start with unit tests, it is faster development. It separates GUI from business logic, which is fine.
Documentation, But Done Right
JIRA would theoretical be ideal, if the requirements would be entirely correct and complete. In your source and version control you could keep references to the ticket when changing something. However that gives a fragmented view at most.
Better would be to do your own documentation of the business logic and further on on the implementing GUI. With change tags to which your code can refer (and vice versa). A change tag might be a JIRA ticket number or your own "legacy code tag."
This helps to reason about the business logic, and explain peculiar features in code and data. Coming back on maintenance will help you doing the best change. It also will give better insights. See questionable things and limitations.
A thin documentation describing the business logic of the system, where you touched it. Concise requirements from the (change) request and your implementation. Listing the classes.
The documentation should be in version control too (like in your personal git). In a text format like .md (mark-down), but GUI mockups (screen shots?) are just as important.
Implementing Change
Do this at the side, without loud mention. It should not take much time.
Only after proven useful, communicate and ask the manager for feedback on your improvement attempts. Depending on how diametral your standpoints, you might opt
for a job change.
Less money perhaps are employed jobs, but they might offer job experience in
a company context, which is valuable.