Taking the risk to adjust the architecture of a legacy system and extend it in a nice and clean way.
Creating a context:
- Complex domain (e.g. life insurance)
- Many technologies are used, tightly coupled (e.g. Redis, db40, iBATIS, Quartz, Sparks, etc).
- The model has been designed around the Active Record (anti)pattern.
- In a few places there are also DAOs and/or Repositories.
- The Service Locator (anti)pattern has been applied everywhere.
- Almost everywhere, the SRP has been violated.
- Communication with any external Web Service is not guarded with a Circuit Breaker.
- And yes.. there are no tests..
(All the above yield sad customers, bugs, and slow performance.)
Against messy, tightly coupled, legacy code
- Strive toward real SOLID principles
- Instead of doing Test-After Development Sins write test code trying to drive the SUT API and safely refactoring afterwards. The non-relevant Test Fixture setup is automated with AutoFixture decleratively with the xUnit.net extension.
- Instead of using the Service Locator use Dependency Injection patterns, such is Constructor Injection.
- Instead of using Active Record, Repositories and DAOs consider using Queries and Commands (as described in the first half of this post). This might result in more classes but each class is going to have one responsibility instead of two or more.
Why it is a risk?
The above require a few changes in the system architecture (e.g. in order to be possible to not use Service Locators, in order to be possible to use Services to query from the database instead of the Active Record way, etc.).
While the required changes are going to (initially) slow down the development process at the end the overall development is going to be faster.
Would you take the risk?