This question already has an answer here:
What is enterprise software, exactly?
8 answers
I've been working for a consulting firm for some time, with clients of various sizes, and I've seen web applications ranging in complexity from really simple:
MVC
Service Layer
EF
DB
To really complex:
MVC
UoW
DI / IoC
Repository
Service
UI Tests
Unit Tests
Integration Tests
But on both ends of the spectrum, the quality requirements are about the same. In simple projects, new devs / consultants can hop on, make changes, and contribute immediately, without having to wade through 6 layers of abstraction to understand what's going on, or risking misunderstanding some complex abstraction and costing down the line.
In all cases, there was never a need to actually make code swappable or reusable - and the tests were never actually maintained past the first iteration because requirements changed, it was too time-consuming, deadlines, business pressure, etc etc.
So if - in the end -
testing and interfaces aren't used
rapid development (read: cost-savings) is a priority
the project's requirements will be changing a lot while in development
...would it be wrong to recommend a super-simple architecture, even to solve a complex problem, for an enterprise client? Is it complexity that defines enterprise solutions, or is it the reliability, # concurrent users, ease-of-maintenance, or all of the above?
I know this is a very vague question, and any answer wouldn't apply to all cases, but I'm interested in hearing from devs / consultants that have been in the business for a while and that have worked with these varying degrees of complexity, to hear if the cool-but-expensive abstractions are worth the overall cost, at least while the project is in development.
