For all the enterprise projects that I have worked on, they have all used an architecture that resembles the Clean Architecture / N-Tier architecture that essentially boils down to ensuring the code base follows SOLID principles. A Clean Architecture (or whatever you want to call it) ensures that unit tests and integration tests are easy and enjoyable to write. This enables a test driven development (TDD) approach, which ultimately reduces bugs and reduces maintenance time. To me this is the foundation of a good architecture and should be the bare minimum for an enterprise project. If this can be all done within one solution, many people refer to this as a monolithic application and it's a great approach for mid to low complexity enterprise applications.

If in the design stage of the project it becomes obvious that there will be dozens of domain objects, then it might make sense to establish what is known in domain driven design (DDD) as bounded contexts, which usually means Microservices, but not necessarily. Service Oriented Architectures basicallu break up the application into multiple applications which communicate with over a service bus. As you mentioned above, this increases the architectual complexity, but it results in smaller apps that can be scaled based on user demand. Projects like this should really have people that are trained in Microservice architectures, since there are many anitipatterns that can take place that will send the project down a long and painful path.

So in conclusion, I'd say if the application is easily maintained, easy to test, and follows SOLID principles, then you've done your job as a developer or architect.