ನಾನು ಕೋಡ್ ಬರೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ ವಿನ್ಯಾಸ ಮಾಡಲಾರಂಭಿಸಿದ್ದು ಏಕೆ
ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿ ಎಂದರೆ ಫೀಚರ್ಗಳನ್ನು (features) ಬರೆಯುವುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತಿದ್ದೆ. ಎಂಟಿಟಿಗಳನ್ನು (entities) ರಚಿಸುವುದು, ಕಂಟ್ರೋಲರ್ಗಳನ್ನು (controllers) ನಿರ್ಮಿಸುವುದು ಮತ್ತು ಡೇಟಾಬೇಸ್ಗಳನ್ನು (databases) ಸಂಪರ್ಕಿಸುವುದು ನನ್ನ ಕೆಲಸ ಎಂದು ನಾನು ಅಂದುಕೊಂಡಿದ್ದೆ.
ಇತ್ತೀಚಿನ ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ನನ್ನ ದೃಷ್ಟಿಕೋನವನ್ನೇ ಬದಲಿಸಿತು. ಕೋಡಿಂಗ್ ಎಂಬುದು ಪರಿಹಾರದ ಒಂದು ಭಾಗ ಮಾತ್ರ ಎಂದು ನಾನು ಕಲಿತೆ. ನೀವು ಒಂದು ಸಾಲು ಕೋಡ್ ಬರೆಯುವ ಮೊದಲೇ ನಿಜವಾದ ಕೆಲಸ ನಡೆಯುತ್ತದೆ.
ನೀವು ಆರ್ಕಿಟೆಕ್ಚರ್ (architecture) ಬಗ್ಗೆ ನಿರ್ಧರಿಸಬೇಕು. ಅದು ಏಕೆ ಸೂಕ್ತವಾಗಿದೆ, ಅದರ ವೆಚ್ಚ ಎಷ್ಟು ಮತ್ತು ಅದು ಯಾವ ಅಪಾಯಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ ಎಂದು ನೀವು ಪ್ರಶ್ನಿಸಬೇಕು.
ನನ್ನ ಪ್ರಮುಖ ಪಾಠಗಳು ಇಲ್ಲಿವೆ:
• ಆರ್ಕಿಟೆಕ್ಚರ್ ಉತ್ಪನ್ನದ ಹಂತಕ್ಕೆ ಅನುಗುಣವಾಗಿರಬೇಕು. ತಕ್ಷಣವೇ microservices, Kubernetes ಮತ್ತು ಸಂಕೀರ್ಣವಾದ event queues ಬಳಸಲು ಆಸೆ ಆಗಬಹುದು. ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ಗಾಗಿ, ನಾವು ಸಿಂಗಲ್ ಪ್ರೊಸೆಸ್ನಲ್ಲಿ ಲೇಯರ್ಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (layered architecture) ಅನ್ನು ಆರಿಸಿಕೊಂಡೆವು. ಇದು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸಿಸ್ಟಮ್ನ (distributed system) ತಲೆನೋವು ಇಲ್ಲದೆ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನಮಗೆ ಅನುವು ಮಾಡಿಕೊಟ್ಟಿತು. ನೀವು ಪ್ರಾರಂಭಿಸುವಾಗ ಸರಳತೆಯೇ ಯಾವಾಗಲೂ ಉತ್ತಮ.
• ಕೆಲವು ನಿರ್ಧಾರಗಳು ಈಗ ಅಗ್ಗವಾಗಿರಬಹುದು ಆದರೆ ನಂತರ ದುಬಾರಿಯಾಗಬಹುದು. ನಾವು ಮೊದಲ ದಿನದಿಂದಲೇ ನಮ್ಮ ಡೇಟಾ ಮಾಡೆಲ್ಗೆ TenantId ಅನ್ನು ಸೇರಿಸಿದೆವು. ನಮಗೆ ಕೇವಲ ಒಬ್ಬ ಕ್ಲೈಂಟ್ ಇದ್ದರೂ ಸಹ, ಇದು ಭವಿಷ್ಯದಲ್ಲಿ SaaS ಮಾಡೆಲ್ಗೆ ಬದಲಾಗುವುದನ್ನು ಸುಲಭಗೊಳಿಸಿತು. ನೀವು ಮಲ್ಟಿ-ಟೆನೆನ್ಸಿ (multi-tenancy) ಸೇರಿಸಲು ತುಂಬಾ ವಿಳಂಬ ಮಾಡಿದರೆ, ಮೈಗ್ರೇಷನ್ (migration) ಒಂದು ದುಸ್ವಪ್ತವಾಗುತ್ತದೆ.
• ವಿನ್ಯಾಸವು ಭವಿಷ್ಯದ ಅಡೆತಡೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ಪ್ರೋಗ್ರಾಮಿಂಗ್ ತಕ್ಷಣದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ವಿನ್ಯಾಸವು ಭವಿಷ್ಯದ ದಾರಿಗಳನ್ನು ಮುಚ್ಚದೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ವಿವಿಧ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ಗೆ (infrastructure) ಬದಲಾಗುವುದನ್ನು ಸುಲಭಗೊಳಿಸಲು ನಾವು ಆರಂಭದಲ್ಲೇ ಕಂಟೇನರ್ಗಳನ್ನು (containers) ಬಳಸಿದೆವು. ಪ್ರೊವೈಡರ್ಗಳನ್ನು ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಲು ನಾವು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು (interfaces) ಬಳಸಿದೆವು.
• ವ್ಯವಹಾರದ ಬದಲಾವಣೆಗಳು ತಾಂತ್ರಿಕ ಬದಲಾವಣೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ವ್ಯವಹಾರ ಬೆಳೆದಂತೆಲ್ಲಾ ಸಿಸ್ಟಮ್ microservices ಗೆ ಬದಲಾಗುತ್ತದೆ. ಒಂದು ಸಿಂಗಲ್ ಕ್ಲಿನಿಕ್ ಆಪ್ ನೂರಾರು ಕ್ಲಿನಿಕ್ಗಳಿಗಾಗಿ SaaS ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಆಗಿ ಬದಲಾಗುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯು ನೀವು ಬಿಲ್ಲಿಂಗ್, ಸಬ್ಸ್ಕ್ರಿಪ್ಶನ್ಗಳು ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.
• ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಸ್ಮಾರ್ಟ್ ಪ್ಯಾಟರ್ನ್ಗಳು ಅಗತ್ಯವಾಗಿವೆ. ನಾವು ಸಿಂಕ್ರೋನಸ್ ಕಾಲ್ಗಳಿಂದ (synchronous calls) ಇವೆಂಟ್-ಡ್ರಿವನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗೆ (event-driven architecture) ಬದಲಾಯಿಸಿದೆವು. ವೈದ್ಯಕೀಯ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ನಿಧಾನಗತಿಯ ನೋಟಿಫಿಕೇಶನ್ ಸೇವೆಯು ಅಪಾಯಿಂಟ್ಮೆಂಟ್ ಬುಕಿಂಗ್ ಅನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಬಾರದು. ಮೆಸೇಜ್ ಬ್ರೋಕರ್ ವಿಫಲವಾದರೂ ಡೇಟಾ ಸುರಕ್ಷಿತವಾಗಿರಲು ನಾವು Outbox ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಬಳಸಿದೆವು.
• ಪ್ಯಾಟರ್ನ್ಗಳು ಡೊಮೇನ್ಗೆ (domain) ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಪ್ಯಾಟರ್ನ್ಗಳನ್ನು ಕುರುಡಾಗಿ ಬಳಸಬೇಡಿ. ವೈದ್ಯಕೀಯ ರೋಗನಿರ್ಣಯಕ್ಕೆ ಬಲವಾದ ಕನ್ಸಿಸ್ಟೆನ್ಸಿ (strong consistency) ಅಗತ್ಯವಿದೆ. ರೋಗಿಯ ಸುರಕ್ಷತೆಗಾಗಿ ನೀವು ಎವೆಂಟುವಲ್ ಕನ್ಸಿಸ್ಟೆನ್ಸಿ (eventual consistency) ಮೇಲೆ ಅವಲಂಬಿತರಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ಅನ್ನು ಹಾಳುಮಾಡಿದರೆ, ಸೂಕ್ಷ್ಮವಾದ ಕ್ಲಿನಿಕಲ್ ಡೇಟಾಕ್ಕಾಗಿ ಕ್ಯಾಶ್ (cache) ಬಳಸಬೇಡಿ.
• DevOps ಎಂಬುದು ನಂತರದ ಆಲೋಚನೆಯಲ್ಲ. ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ (deployment), ಹೆಲ್ತ್ ಚೆಕ್ಗಳು (health checks) ಮತ್ತು ಪೈಪ್ಲೈನ್ಗಳು (pipelines) ಆರಂಭಿಕ ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿವೆ. ನೀವು ವೆಚ್ಚಗಳನ್ನು ಅಂದಾಜಿಸಬೇಕು ಮತ್ತು ನಿಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ನಿಜವಾಗಿಯೂ ಪೂರಕವಾಗಿರುವ ಘಟಕಗಳನ್ನು (components) ಆರಿಸಿಕೊಳ್ಳಬೇಕು.
ಪ್ರೋಗ್ರಾಮರ್ ಮತ್ತು ಡಿಸೈನರ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೆಂದರೆ "ಏಕೆ" ಎಂಬ ಪ್ರಶ್ನೆ.
ಪ್ರೋಗ್ರಾಮರ್ ಕೇಳುತ್ತಾರೆ: "ಇದನ್ನು ನಾನು ಹೇಗೆ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡಲಿ?" ಡಿಸೈನರ್ ಕೇಳುತ್ತಾರೆ: "ಈ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗೆ ಇದು ಏಕೆ ಸರಿಯಾದ ಪರಿಹಾರ?"