Our team needs to add a new line of business to our existing system and have a somewhat short deadline (2ish months).

Unfortunately like any 15+ year system, it wasn't really written with the understanding that a new line could be added.

Essentially, we've got an overgrown LoanQuote class and an overgrown LoanAccount class that represent bank loans.

The new line of business still involves the concept of loan quotes and loan accounts, yet the properties, processes, and calculations are very different.

I've taken like four different stabs at breaking it apart and I'm not sure which strategy I should pull the trigger on and commit.

I've tried:

1. Refactoring the original line of business behavior into a Strategy so I could reuse the LoanQuote class with different strategies for each line of business. I found that the LoanQuote class is so heavily permeated with behavior from the original line of business that it would still be a mess.

2. Creating a base class that only contains the shared properties between line of business. The base class really only handles saving and loading. I'd be sharing the DB tables so the table would have to contain the properties from both line of businesses. Same as option 1. The existing application would continue working just by instantiating the inherited original line of business subclass. I'd need new UI that would deal with the subclass of the new line of business.

3. Avoiding the original line of business code entirely, no inheritance, no composition, just new classes, new storage, sort of like DDD bounded context. It lives in the same codebase, shares some entities, but needs a lot of new UI and new tables.

It's overwhelming because I've never had to do something like this. I'd really like to reuse the quote and account classes because they are the primary objects in the system, but I'm concerned mixing them via inheritance is just going to make a bigger ball of mud.

Has anyone had a similar experience? With a 2 month deadline? How did you handle it?