You know, this:
Convincing a development team to use a better design pattern
Is a fair bit different from this:
I recently joined a company where I was tasked with building a system for one of their clients. The work I've done is so far working well, but the most senior developer on the team who's been with the company for many years is having trouble understanding my code. He says it's hard to follow.
In your title you sound like you're one of those guys full of book learning, ideals, and little experience who blames every difficulty with the existing code base on the teams outdated ideas.
In your opening paragraph though you're working on a green field project and are only having trouble with a peer review.
These are wildly different situations. Old code bases will always be full of old ideas. When we make changes in them we tend to fall into their framework and perpetuate the old ideas. It's expensive not to. We work to modernize them but somehow something from the past always hangs on. They effect even the way we think.
However, you're working on a new project. No old code to tie you to the past. You're problem isn't convincing a team to use a better design pattern. It's convincing them that they can understand one you've used.
I tried conducting a training session for him and another developer where I explained the design patterns used in this program. The system is written in Ruby on Rails and I used a design pattern called the "Clean Architecture" to better modularize all the functionality. During my presentation, the senior developer scoffed at some of the concepts. He feels that the Clean Architecture introduces a lot of unnecessary complexity because it involves so many layers of abstraction and objects.
If what you're writing is a one-off he's right. Clean Architecture doesn't minimize complexity, abstraction, or object count. It minimizes the impact of change. That's only valuable once you move past one-off thinking to how this thing is maintained over time.
The developers on my team don't seem to unit test as thoroughly as I do, and don't see the need to learn a new conceptual framework. However, I've worked at other organizations running large applications that run into scalability problems when using the default problem solving approaches popular in Ruby on Rails. Seeing how those teams solved such problems and made their codebase more maintainable using SOLID and Clean Architecture is why I think it's a great way approach to the program I'm building at my current employer. None of my coworkers at this company had exposure to anything like that yet. Neither of them ever heard of SOLID.
That means what you're doing is nearly as bad as coming in and programming in a language none of them has ever heard of.
My concern is that the other developers on my team will eventually push back on the design patterns I'm using and try to micromanage my work. Maybe I'm not great at articulating the advantages of the way I code - I just go by what I know works from past experiences. It is especially troubling to me that one of my coworkers finds my code to be "hard". What do you think is the best way of handling this situation?
You're focused on the one guy who finds your code to be "hard". What about the others? Always be willing to accept the idea that, despite following Clean Architecture, your code might suck. You need someone, besides you, to tell you when it's understandable. Don't hide behind ideological differences. Only once you've gotten someone to admit they can understand your code should you push your ideological detractors.
The way to push them is to evangelize. Don't force them. Convince them. If you're not Uncle Bob don't try to be Uncle bob. Giving long winded, one way presentations is not how I'd go about it. Ask questions. Learn what they do believe in. What concerns they have. What problems keep cropping up. Be willing to admit Clean Architecture doesn't solve every problem. Show them what it does solve. Show them how you can react to unforeseen change. Get them interested. Then you can explain why you don't solve everything with one object.