4.2 KiB
4.2 KiB
SOLID Refactoring Plan for Pipefy Project
This document outlines a step-by-step plan to refactor the Pipefy project to comply with SOLID principles. Check off each step as you complete it.
1. Preparation
- Review current codebase and identify major responsibilities in
Program.csanddata.cs.- Program.cs: Handles configuration loading, user interaction, API communication, JSON deserialization, database access, data comparison, record creation, console output, timer logic, and orchestration.
- data.cs: Contains data models for API responses, business entities, and configuration. No business logic.
- List all external dependencies (API, database, configuration).
- Pipefy API: Used for fetching and creating records (GraphQL over HTTP, requires API token and table IDs).
- Access Database: Used for reading local records (via OleDb, requires DB path and password).
- Configuration: Loaded from
appsettings.json(contains DB path, API token, API URL, table IDs). - NuGet Packages: Microsoft.Extensions.Configuration, Newtonsoft.Json, System.Data.OleDb, etc.
2. Project Structure
- Create folders:
Services/,Models/,Mappers/(if needed).Services/: For service and interface implementations (API, DB, config, business logic).Models/: For data models (move fromdata.cs).Mappers/: For mapping logic between API/DB and domain models (optional, if mapping grows).- Integrate ORM (e.g., Entity Framework Core) to abstract DB access and ease future DB changes. (Next step)
- Note: Current structure is well-separated; ORM will further improve OCP and testability.
- Move or create files as needed for separation of concerns.
3. Single Responsibility Principle (SRP)
- Extract configuration loading into
IConfigurationServiceandConfigurationService. - Extract Pipefy API logic into
IPipefyApiServiceandPipefyApiService. - Extract database logic into
IDatabaseServiceandDatabaseService. - Extract data mapping logic into
IDataMapperandDataMapper. - Extract business logic (comparison, orchestration) into
IBusinessLogicServiceandBusinessLogicService. - Remove static business/data methods from
Program.csand ensure all logic is in services.- Note: All main responsibilities are separated. Consider splitting services further if logic grows (e.g., separate API read/write, config providers).
4. Open/Closed Principle (OCP)
- Define interfaces for each service (already done: IConfigurationService, IPipefyApiService, IDatabaseService, IDataMapper, IBusinessLogicService).
- Ensure new data sources or logic can be added by implementing new classes, not modifying existing ones (all main logic is now behind interfaces and DI).
- Note: Future data sources or logic can be added via new classes.
5. Liskov Substitution Principle (LSP)
- Ensure all service implementations can be replaced by their interfaces without breaking functionality.
- Note: Add/expand unit tests to verify all service implementations can be swapped without breaking consumers. Ensure interfaces do not expose implementation-specific details.
6. Interface Segregation Principle (ISP)
- Keep interfaces focused and small.
- Split large interfaces if needed.
- Note: Review interfaces for granularity. Split any that grow too large or have unrelated methods.
7. Dependency Inversion Principle (DIP)
- Refactor
Program.csto depend on abstractions (interfaces), not concrete classes. - Use dependency injection to provide services to the main program.
8. Testing
- Add or update unit tests for each service.
- Ensure business logic is testable in isolation.
- Note: Prioritize unit tests for business logic and service interfaces. Use mocks/fakes to test substitutability and isolation.
9. Documentation
- Update this plan as you progress.
- Document new structure and usage in a
README.mdor similar file.- Note: Document service responsibilities and interface contracts. Add XML comments to public APIs.
Progress Tracking:
- Mark each step as complete (
[x]) as you finish it. - Add notes or decisions below each step if needed.
Last updated: May 19, 2025