You're gonna take heat for that position, but I'd support you, having been in the same position. Came to a team in a company that had a handful of services wher

You're gonna take heat for that position, but I'd support you, having been in the same position. Came to a team in a company that had a handful of services where folks had been "doing things" in an FP manner where it was entirely inappropriate (CRUD app, without going into details). The had wonderfully illegible, but functional, code that was lacking required basics like transaction management, yet were befuddled as to why certain integration tests or deployments were behaving unpredictably. Similar to your situation, the original decision makers were long gone by the time I arrived. It never ceases to amaze me how far you can get with going back to basics of solid software engineering and the manifestations of those basics, mainly: 1. OOP to prove that you have a good grasp of the domain and problem space. Show me you know what's actually happening through code and tests. 2. Build relations - it's far, far, FAR easier to go from BCNF/3NF to a denormalized state than the opposite when you've got lots of data. It's also far easier to perform operations on that normalized state with certainty that your change will fucking work. 3. Focus on APIs first. Whatever the bounded context, focus on the APIs and how they'll be consumed.