හිතන්න ඔයා පොඩි web application එකක් හදනවා කියලා.

මුලදී වැඩේ ලේසියි. Pages කිහිපයක් හදනවා, Backend එක ලියනවා, Database එක connect කරනවා. Application එක හොඳට වැඩ කරනවා.

හැබැයි ටික ටික application එක ලොකු වෙනවා.

දැන් ඒකට Login, Payments, Notifications, File Uploads, Reports, Admin Panel, APIs වගේ දේවල් එකතු වෙනවා.

එතකොට මුලදී ලියපු code එක වෙනස් කරන්න ගියාම, වෙනත් තැනක තියෙන දෙයක් කැඩෙන්න පටන් ගන්න පුළුවන්.

මෙතනදී තමයි Software Architecture වැදගත් වෙන්නේ.

Software Architecture කියන්නේ සරලවම software system එකක ප්‍රධාන කොටස් කොහොම සංවිධානය කරනවාද, ඒ කොටස් එකිනෙක සමඟ කොහොම වැඩ කරනවාද, සහ එක් එක් කොටසට තියෙන වගකීම මොකක්ද කියන එක තීරණය කරන ආකාරය.

Software Architecture එකක් කියන්නේ මොකක්ද?

Software Architecture එකක් කියන්නේ software system එකේ විශාල මට්ටමේ ව්‍යුහයට.

ඒකෙන් අපි තීරණය කරන දේවල් අතර:

• System එකේ ප්‍රධාන කොටස් මොනවාද?

• එක් එක් කොටස කරන්නේ මොනවාද?

• ඒ කොටස් එකිනෙක සමඟ සන්නිවේදනය කරන්නේ කොහොමද?

• Data තියාගන්නේ කොහෙද?

• User සහ system එක අතර සම්බන්ධය කොහොමද?

• Security, Performance සහ Scalability හසුරුවන්නේ කොහොමද?

වගේ දේවල් තියෙනවා.

මේක ගෙයක් හදනවා හා සමානයි.

ගෙයක් හදන්න කලින්:

• කාමර කොහෙද?

• Kitchen එක කොහෙද?

• විදුලි රැහැන් යන්නේ කොහෙන්ද?

• Water pipes යන්නේ කොහෙන්ද?

• එක කොටසක් තවත් කොටසකට සම්බන්ධ වෙන්නේ කොහොමද?

වගේ දේවල් සැලසුම් කරනවා.

Software එකත් ඒ වගේ.

Architecture කියන්නේ software එකේ ප්‍රධාන කොටස් එකට ගැළපෙන්නේ කොහොමද කියන සැලැස්ම.

Architecture එක වැදගත් ඇයි?

පොඩි application එකකට architecture ගැන ලොකු දෙයක් හිතන්න අවශ්‍ය නැහැ වගේ පේන්න පුළුවන්.

උදාහරණයක් විදිහට Calculator application එකක් හදනවා නම්, ඒකට services පහක් දාලා complicated architecture එකක් හදන්න අවශ්‍ය නැහැ.

හැබැයි University Management System එකක් හිතන්න.

ඒකේ:

Students
Teachers
Courses
Attendance
Exams
Payments
Notifications
Reports
Authentication

වගේ features ගොඩක් තියෙන්න පුළුවන්.

මේ හැම දෙයක්ම එකම තැනක mix කරලා තිබුණොත් application එක maintain කරන්න අමාරු වෙනවා.

හොඳ Architecture එකක් නිසා:

Maintain කරන්න ලේසි වෙනවා

System එකේ කොටස් පැහැදිලිව වෙන් කරලා තියෙන නිසා code එක තේරුම් ගන්නත් වෙනස් කරන්නත් ලේසියි.

System එක scale කරන්න ලේසි වෙනවා

Users වැඩි වුණාම හෝ features වැඩි වුණාම මුළු application එකම නැවත හදන්න අවශ්‍ය නොවෙන්න පුළුවන්.

Security හොඳින් පාලනය කරන්න පුළුවන්

Sensitive operations වෙනත් කොටස්වලින් වෙන් කරලා ආරක්ෂා කරන්න පුළුවන්.

Performance වැඩි දියුණු කරන්න පුළුවන්

System එකේ Heavy කොටස් හඳුනාගෙන ඒවා වෙනම optimize කරන්න පුළුවන්.

Team එකකට එකට වැඩ කරන්න ලේසි වෙනවා

Developer කෙනෙක් Student part එකේ වැඩ කරද්දි තවත් developer කෙනෙක්ට Payment part එකේ වැඩ කරන්න පුළුවන්.

ඒ නිසා Architecture කියන්නේ application එක ලස්සනට organize කරන දෙයක් විතරක් නෙවෙයි.

Software එක හදන්න, වෙනස් කරන්න, test කරන්න, secure කරන්න සහ ලොකු කරන්න කොච්චර ලේසිද කියන එකටත් Architecture එක බලපානවා.

Software Architectures වර්ග කිහිපයක්

හැම application එකකටම එකම Architecture එක ගැළපෙන්නේ නැහැ.

Application එකේ අවශ්‍යතා අනුව වෙනස් approaches භාවිතා කරනවා.

1. Monolithic Architecture

Monolithic Architecture එක තේරුම් ගන්න ලේසිම විදිහ තමයි:

Application එකේ ප්‍රධාන වැඩ හැම එකක්ම එක application එකක් ඇතුළේ තියෙනවා.

උදාහරණයක්:

              Web Application
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
   Authentication Products    Payments
        │           │           │
        └───────────┼───────────┘
                    ↓
                 Database

Frontend, Backend logic, Authentication, Payments වගේ කොටස් එකම application එකක කොටස් වෙන්න පුළුවන්.

උදාහරණයක් විදිහට:

Next.js Application
        ↓
PostgreSQL

හෝ:

Laravel Application
        ↓
MySQL

වාසි

• Develop කරන්න ලේසියි

• Deploy කරන්න ලේසියි

• පොඩි projects සඳහා තේරුම් ගන්න ලේසියි

• Infrastructure අඩුයි

• Maintain කරන්නත් සාමාන්‍යයෙන් පහසුයි

අවාසි

Application එක ගොඩක් ලොකු වුණාම:

• Codebase එක manage කරන්න අමාරු වෙන්න පුළුවන්

• පොඩි feature එකක් deploy කරන්නත් මුළු application එක deploy කරන්න වෙන්න පුළුවන්

• එක් එක් කොටස වෙන වෙනම scale කරන්න අමාරුයි

• එක කොටසක problem එකක් මුළු application එකටම බලපාන්න පුළුවන්

Monolithic කියන්නේ නරක Architecture එකක් කියන එක නෙවෙයි.

Student projects, small businesses, startups සහ medium-sized applications ගොඩකට හොඳින් organize කරපු Monolith එකක් ඉතා හොඳ තේරීමක් වෙන්න පුළුවන්.

2. Layered Architecture

Layered Architecture එකේ application එක විවිධ layers වලට බෙදනවා.

සාමාන්‍ය structure එකක් මෙහෙම වෙන්න පුළුවන්:

          User
            ↓
        Frontend
            ↓
        Controller
            ↓
         Service
            ↓
       Repository
            ↓
        Database

එක් එක් layer එකට වෙනම වගකීමක් තියෙනවා.

Presentation Layer

User දකින සහ භාවිතා කරන කොටස.

උදාහරණ:

• Web pages

• Mobile screens

• UI components

Business Layer

Application එකේ rules සහ actual business logic මෙතන තියෙනවා.

උදාහරණයක්:

Course එක full නම් student කෙනෙකුට ඒ course එකට register වෙන්න බැහැ.

මේ වගේ rule එකක් Business Layer එකේ තියෙන්න පුළුවන්.

Data Access Layer

Database එක සමඟ වැඩ කරන කොටස.

උදාහරණ:

GetStudent()
CreateCourse()
UpdateAttendance()

Database

Application එකේ actual data store කරන තැන.

මේ layers වෙන් කරලා තිබීම නිසා application එකේ එක් එක් කොටස තේරුම් ගන්න ලේසි වෙනවා.

3. Client-Server Architecture

ඔයා මේ Architecture එක දැනටමත් භාවිතා කරලා ඇති.

Website එකක් Browser එකෙන් open කරනකොට ඔයාගේ device එක Client එකක් විදිහට වැඩ කරනවා.

Server එක request එක process කරලා response එකක් එවනවා.

       Client
    Web Browser
         │
      Request
         ↓
       Server
         │
      Database
         │
      Response
         ↓
       Client

උදාහරණයක් විදිහට website එකකට Login වෙනකොට:

Browser
   ↓
POST /login
   ↓
Backend Server
   ↓
Database
   ↓
Check Login Details
   ↓
Response
   ↓
Browser

Modern Web Applications වල මූලික අදහස් අතර Client-Server Architecture එකත් තියෙනවා.

4. Microservices Architecture

දැන් හිතන්න University System එකක්, ගොඩක් ලොකු වුණා කියලා.

එකම application එකක් විදිහට තියාගන්නවා වෙනුවට, ඒක පොඩි පොඩි services වලට බෙදන්න පුළුවන්.

                    API Gateway
                         │
       ┌─────────────────┼─────────────────┐
       ↓                 ↓                 ↓
 Student Service   Payment Service   Course Service
       │                 │                 │
   Database          Database          Database

හැම Service එකකටම විශේෂ වගකීමක් තියෙනවා.

Student Service

• Student profiles

• Student information

• Student registration

Payment Service

• Payments

• Invoices

• Transactions

Course Service

• Courses

• Enrolment

• Course information

මේ Services වෙන වෙනම develop, deploy සහ scale කරන්න පුළුවන්.

Microservices භාවිතා කරන්නේ ඇයි?

හිතන්න Payment Service එකට අනෙක් කොටස්වලට වඩා 10 ගුණයක traffic එකක් එනවා කියලා.

Microservices Architecture එකකදී Payment Service එක විතරක් වැඩිපුර scale කරන්න පුළුවන්.

මුළු application එකම scale කරන්න අවශ්‍ය නැහැ.

හැබැයි මෙතන ලොකු trade-off එකක් තියෙනවා.

Microservices නිසා:

• Applications කිහිපයක් manage කරන්න වෙනවා

• Deployments කිහිපයක් තියෙනවා

• Network communication අවශ්‍ය වෙනවා

• Services අතර Authentication අවශ්‍ය වෙන්න පුළුවන්

• Monitoring සහ Logging වැඩි වෙනවා

• එක් Service එකක් down වුණොත් වෙනත් Services වලට බලපාන්න පුළුවන්

ඒ නිසා Microservices කියන්නේ application එක ලොකුයි කියලා අනිවාර්යයෙන්ම තෝරන්න ඕන දෙයක් නෙවෙයි.

Services වැඩි වෙන තරමට manage කරන්න ඕන දේවලුත් වැඩි වෙනවා.

5. Serverless Architecture

Serverless කියන්නේ traditional විදිහට අපිම servers manage නොකර, අවශ්‍ය වෙලාවට run වෙන Functions සහ Cloud services භාවිතා කරන approach එකක්.

සරලව:

User
 ↓
API
 ↓
Function
 ↓
Database

උදාහරණයක් විදිහට User කෙනෙක් image එකක් upload කළා කියලා හිතන්න.

Image Upload
     ↓
  Storage
     ↓
Function Trigger
     ↓
Resize Image
     ↓
Save Result

මෙතන Cloud provider එක server infrastructure එකේ විශාල කොටසක් manage කරනවා.

Serverless කියන්නේ servers නැති බව නෙවෙයි.

Servers තියෙනවා.

නමුත් ඒවා manage කිරීමේ වගකීමෙන් විශාල කොටසක් Cloud provider එකට යනවා.

වාසි

• අවශ්‍යතාවය අනුව automatically scale වෙන්න පුළුවන්

• Usage එක අනුව වියදම් පාලනය කරන්න පුළුවන්

• Server management අඩුයි

• Event-based වැඩ සඳහා හොඳයි

අවාසි

• Cloud provider එක මත වැඩිපුර depend වෙන්න පුළුවන්

• සමහර අවස්ථාවල startup delay එකක් ඇති වෙන්න පුළුවන්

• Debugging සමහර systems වලදී අමාරු වෙන්න පුළුවන්

• හැම application එකකටම ගැළපෙන්නේ නැහැ

6. Event-Driven Architecture

Event-Driven Architecture එකේ components එකිනෙකා සමඟ events හරහා communicate කරනවා.

උදාහරණයක් බලමු.

Customer කෙනෙක් order එකක් දැම්මා.

Customer Places Order
        ↓
    OrderCreated
        ↓
 ┌──────┼─────────┐
 ↓      ↓         ↓
Email  Payment  Inventory

Order system එකට හැම වැඩක්ම තමන්ම කරන්න අවශ්‍ය නැහැ.

ඒ වෙනුවට:

OrderCreated

කියන event එකක් publish කරන්න පුළුවන්.

ඊට පස්සේ වෙනත් systems ඒ event එකට අනුව තමන්ගේ වැඩ කරනවා.

උදාහරණයක්:

• Email Service → Confirmation email එක යවනවා

• Payment Service → Payment එක process කරනවා

• Inventory Service → Stock එක update කරනවා

එකම event එකකට systems කිහිපයක් ප්‍රතිචාර දක්වන අවස්ථාවලදී මේ approach එක ගොඩක් ප්‍රයෝජනවත්.

7. MVC Architecture

Web development කරන කෙනෙක් නම් MVC කියන නම අනිවාර්යයෙන්ම අහලා ඇති.

MVC කියන්නේ:

Model → View → Controller

          User
           ↓
       Controller
        ↙       ↘
     Model      View
       ↓          ↓
   Database       UI

Model

Data සහ data සම්බන්ධ logic handle කරන කොටස.

View

User දකින interface එක.

Controller

Userගෙන් එන request එක ලබාගෙන අවශ්‍ය වැඩ coordinate කරන කොටස.

උදාහරණයක්:

User clicks "View Profile"
          ↓
    ProfileController
          ↓
       User Model
          ↓
       Database
          ↓
      Controller
          ↓
     Profile View

Laravel වගේ Web Frameworks සමඟ MVC Architecture එක නිතරම දකින්න ලැබෙනවා.

එහෙනම් හොඳම Architecture එක මොකක්ද?

එකම හොඳම Architecture එකක් නැහැ.

මේක Software Architecture ඉගෙනගන්නකොට මතක තියාගන්න වැදගත්ම දෙයක්.

Software Architecture සහ Software Design අතර වෙනස

මේ දෙක එකම දෙයක් වගේ පේන්න පුළුවන්.

හැබැයි දෙක අතර වෙනසක් තියෙනවා.

Software Architecture

System එකේ විශාල මට්ටමේ structure එක ගැන බලනවා.

උදාහරණ:

Monolith එකක්ද Microservices ද?

Services එකිනෙක communicate කරන්නේ කොහොමද?

Data store කරන්නේ කොහෙද?

Software Design

System එකේ එක් එක් කොටස ඇතුළෙන් හදන්නේ කොහොමද කියන එක ගැන වැඩිපුර බලනවා.

උදාහරණ:

මේ class එක වැඩ කරන්නේ කොහොමද?

මේ function එක handle කරන්න ඕන මොන logic එකද?

මේ problem එකට මොන Design Pattern එක භාවිතා කරනවද?

සරලව මතක තියාගන්න:

Architecture = නගරයේ විශාල සැලැස්ම

Design = එක් එක් ගොඩනැගිල්ලේ සැලැස්ම

Architecture එකෙන් විශාල structure එක සහ ඒවා අතර සම්බන්ධතා බලනවා.

Design එකෙන් ඒ කොටස් ඇතුළෙන් හදන ආකාරය ගැන බලනවා.

Architecture එක තෝරනකොට මොනවා ගැනද හිතන්න ඕන?

Architecture එකක් තෝරනකොට “මොකක්ද අලුත්ම technology එක?” කියලා බලන එකට වඩා, වැදගත්:

1. System එකට ඇත්තටම අවශ්‍ය මොනවාද?

2. ඉස්සරහට මේක කොච්චර ලොකු වෙයිද?

3. Users කීදෙනෙක් ඉන්නවාද?

4. වෙන වෙනම scale කරන්න ඕන කොටස් තියෙනවාද?

5. System එකේ reliability කොච්චර වැදගත්ද?

6. මේ complexity එක manage කරන්න Team එකට පුළුවන්ද?

7. ඇත්තටම මේ තරම් complicated Architecture එකක් අවශ්‍යද?

මේ ප්‍රශ්නවලට ලැබෙන පිළිතුරු තමයි Architecture එක තෝරගන්න උදව් කරන්නේ.