আমি কেন কোড লেখা বন্ধ করে ডিজাইন করা শুরু করলাম
আমি ভাবতাম সফটওয়্যার ডেভেলপমেন্ট মানেই হলো ফিচার লেখা। আমি মনে করতাম আমার কাজ হলো entities তৈরি করা, controllers বানানো এবং databases কানেক্ট করা।
একটি সাম্প্রতিক প্রজেক্ট আমার দৃষ্টিভঙ্গি বদলে দিয়েছে। আমি শিখেছি যে কোডিং হলো সমাধানের একটি অংশ মাত্র। আসল কাজ শুরু হয় কোডের একটি লাইন লেখার আগেই।
আপনাকে আর্কিটেকচার নিয়ে সিদ্ধান্ত নিতে হবে। আপনাকে প্রশ্ন করতে হবে এটি কেন উপযুক্ত, এর খরচ কত এবং এটি কোন ঝুঁকিগুলো দূর করে।
এখানে আমার প্রধান শিক্ষাগুলো দেওয়া হলো:
• আর্কিটেকচার অবশ্যই প্রোডাক্টের পর্যায়ের সাথে সামঞ্জস্যপূর্ণ হতে হবে। শুরুতেই microservices, Kubernetes এবং জটিল event queues ব্যবহার করার ইচ্ছা জাগতে পারে। আমাদের প্রজেক্টের জন্য, আমরা একটি single process-এর মধ্যে layered architecture বেছে নিয়েছিলাম। এটি আমাদের একটি distributed system-এর জটিলতা ছাড়াই দায়িত্বগুলো আলাদা করতে সাহায্য করেছে। শুরুতে সহজ পদ্ধতি অবলম্বন করাই প্রায়শই শ্রেয়।
• কিছু সিদ্ধান্ত এখন সস্তা মনে হলেও পরে তা অনেক ব্যয়বহুল হয়ে দাঁড়াতে পারে। আমরা প্রথম দিন থেকেই আমাদের ডাটা মডেলে একটি TenantId যোগ করেছিলাম। যদিও আমাদের তখন মাত্র একজন ক্লায়েন্ট ছিল, এটি ভবিষ্যতে SaaS মডেলে স্থানান্তরিত হওয়া সহজ করে দিয়েছে। আপনি যদি multi-tenancy যোগ করার জন্য অনেক বেশি দেরি করে ফেলেন, তবে মাইগ্রেশন একটি দুঃস্বপ্নে পরিণত হতে পারে।
• ডিজাইন ভবিষ্যতের প্রতিবন্ধকতা রোধ করে। প্রোগ্রামিং একটি তাৎক্ষণিক সমস্যার সমাধান করে। ডিজাইন এমনভাবে সমস্যা সমাধান করে যা ভবিষ্যতের পথ বন্ধ করে দেয় না। আমরা বিভিন্ন ইনফ্রাস্ট্রাকচারে সহজে স্থানান্তরের জন্য শুরুতেই containers ব্যবহার করেছি। প্রোভাইডার পরিবর্তন করা সহজ করতে আমরা interfaces ব্যবহার করেছি।
• ব্যবসায়িক পরিবর্তনই টেকনিক্যাল পরিবর্তনকে ত্বরান্বিত করে। ব্যবসা বড় হওয়ার কারণে একটি সিস্টেম microservices-এ রূপান্তরিত হয়। একটি মাত্র ক্লিনিকের অ্যাপ শত শত ক্লিনিকের জন্য একটি SaaS প্ল্যাটফর্মে পরিণত হয়। এই পরিবর্তনটি আপনার বিলিং, সাবস্ক্রিপশন এবং স্কেলিং করার পদ্ধতি বদলে দেয়।
• নির্ভরযোগ্যতার জন্য স্মার্ট প্যাটার্ন প্রয়োজন। আমরা synchronous calls থেকে event-driven architecture-এ চলে এসেছি। একটি মেডিকেল সিস্টেমে, একটি ধীরগতির নোটিফিকেশন সার্ভিস যেন অ্যাপয়েন্টমেন্ট বুকিং প্রক্রিয়াকে ক্র্যাশ না করে। মেসেজ ব্রোকার ব্যর্থ হলেও ডাটা সুরক্ষিত রাখতে আমরা Outbox pattern ব্যবহার করেছি।
• প্যাটার্ন অবশ্যই ডোমেইনের সাথে সামঞ্জস্যপূর্ণ হতে হবে। অন্ধভাবে প্যাটার্ন ব্যবহার করবেন না। একটি মেডিকেল ডায়াগনোসিসের জন্য strong consistency প্রয়োজন। রোগীর নিরাপত্তার জন্য আপনি eventual consistency-এর ওপর নির্ভর করতে পারেন না। সেনসিটিভ ক্লিনিকাল ডাটার ক্ষেত্রে cache ব্যবহার করবেন না যদি তা আপনার audit trail নষ্ট করে দেয়।
• DevOps কোনো afterthought নয়। Deployment, health checks এবং pipelines প্রাথমিক ডিজাইনেরই অংশ। আপনাকে খরচ অনুমান করতে হবে এবং এমন কম্পোনেন্ট বেছে নিতে হবে যা প্রকৃতপক্ষে আপনার প্রয়োজন মেটাতে পারে।
একজন প্রোগ্রামার এবং একজন ডিজাইনারের মধ্যে পার্থক্য হলো "কেন"।
একজন প্রোগ্রামার জিজ্ঞাসা করেন: "আমি এটি কীভাবে কাজ করাব?" একজন ডিজাইনার জিজ্ঞাসা করেন: "এই নির্দিষ্ট সমস্যার জন্য এটিই কেন সঠিক সমাধান?"