I agree with what you are saying. However, I've run into two issues with this when writing corporate in-house services in the .NET environment.
First, the repository pattern as done with Entity Framework has become so prevalent that any other solution or pattern is immediately regarded as "wrong". This means adding a considerable amount of ORM design and coding overhead where it may not be needed.
Second, you are rarely working with a totally new system. Instead, there's almost always a huge technical debt of legacy systems. Most of them have been built up over many years with feature after feature being added, sometimes in a haphazard fashion. This has led to tight coupling and a resistance to making changes because of what that refactoring would break.
I think you have already made it clear with "corporate in-house services" which are surely not microservices. And if you are not working with totally new systems are they even microservices? :)
Part of our goal is to reduce the current technical debt by moving legacy to a new microservice architecture. However, there is considerable legacy code that has to be kept running while this new work is being done. The challenge is to create the new service structure while keeping the old, which is everything from old VB6 desktop apps to tightly coupled WCF services, running. This creates considerable drag on our development process due to the fragility of these old systems and resistance to making changes. I think this is something anyone working in a environment that's been in production a long time is going to encounter.
It's a great place to work. They are making a huge investment in upgrading technology. But there's a lot of work to be done and there are some challenges.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with what you are saying. However, I've run into two issues with this when writing corporate in-house services in the .NET environment.
First, the repository pattern as done with Entity Framework has become so prevalent that any other solution or pattern is immediately regarded as "wrong". This means adding a considerable amount of ORM design and coding overhead where it may not be needed.
Second, you are rarely working with a totally new system. Instead, there's almost always a huge technical debt of legacy systems. Most of them have been built up over many years with feature after feature being added, sometimes in a haphazard fashion. This has led to tight coupling and a resistance to making changes because of what that refactoring would break.
I think you have already made it clear with "corporate in-house services" which are surely not microservices. And if you are not working with totally new systems are they even microservices? :)
Part of our goal is to reduce the current technical debt by moving legacy to a new microservice architecture. However, there is considerable legacy code that has to be kept running while this new work is being done. The challenge is to create the new service structure while keeping the old, which is everything from old VB6 desktop apps to tightly coupled WCF services, running. This creates considerable drag on our development process due to the fragility of these old systems and resistance to making changes. I think this is something anyone working in a environment that's been in production a long time is going to encounter.
Yes. Looks like you need find a new and better place to work may be :).
It's a great place to work. They are making a huge investment in upgrading technology. But there's a lot of work to be done and there are some challenges.