GoDasturchi
Service Boundaries

Service Boundaries

Servis chegaralari

Qo'shni ikkita davlatni tasavvur qiling: ularning chegarasi noaniq bo'lsa (qaysi hudud kimga tegishli — aniq emas), doimiy nizolar chiqadi. Chegara aniq chizilgan bo'lsa, har bir davlat o'z hududida mustaqil qaror qabul qiladi. Mikroservislarda ham xuddi shunday: har bir servisning chegarasi — u nima uchun javobgar, nima uchun EMAS — aniq belgilanishi shart.

Yaxshi chegara belgilashning oltin qoidasi — bitta biznes qobiliyati, bitta servis. "OrderService" faqat buyurtmalar bilan bog'liq ishni qiladi (yaratish, bekor qilish, holatini yangilash) — u hech qachon to'lovni HAQIQATAN amalga oshirmaydi (bu — PaymentServicening ishi) yoki ombordagi qoldiqni HAQIQATAN kamaytirmaydi (bu — InventoryServicening ishi).

example.go
package main

import "fmt"

// YOMON chegara: OrderService boshqa servislarning ishini ham o'zi bajaradi
type OrderServiceBad struct{}

func (s *OrderServiceBad) CreateOrder() string {
	// bu yerda to'lovni HAM, omborni HAM to'g'ridan-to'g'ri o'zgartiradi — chegara xira!
	return "buyurtma yaratildi, to'lov olindi, ombor kamaytirildi"
}

// YAXSHI chegara: OrderService faqat buyurtma holatini boshqaradi,
// boshqa ishlarni BOSHQA servislarga ISHONIB TOPSHIRADI (keyingi darslarda ko'ramiz)
type Order struct {
	ID     string
	Status string
}

type OrderService struct {
	orders map[string]*Order
}

func NewOrderService() *OrderService {
	return &OrderService{orders: make(map[string]*Order)}
}

func (s *OrderService) CreateOrder(id string) *Order {
	order := &Order{ID: id, Status: "pending"}
	s.orders[id] = order
	return order
}

func main() {
	svc := NewOrderService()
	order := svc.CreateOrder("ord-1")
	fmt.Println(order.ID, order.Status)
}

OrderServiceBad — chegarasi "xira": u o'z vazifasidan tashqariga chiqib, boshqa xizmatlarning ishini ham o'zi bajaradi. Bu — "Interface Design" kursida ko'rgan "interfeys ifloslanishi" muammosining servis darajasidagi ko'rinishi: agar to'lov mantig'i o'zgarsa, OrderServiceni ham o'zgartirish kerak bo'ladi, garchi u buyurtma bilan bog'liq hech narsa o'zgarmagan bo'lsa ham.

OrderService (yaxshi versiya) esa FAQAT buyurtma holatini (pending, paid, shipped...) boshqaradi. To'lov va omborni haqiqatan o'zgartirish — boshqa servislarning vazifasi, OrderService ular bilan faqat so'rov yuborish orqali "gaplashadi" (keyingi darsda ko'ramiz). Bu ajratish — kelajakda to'lov tizimini butunlay almashtirish kerak bo'lsa ham, OrderServicega tegmasdan qilish imkonini beradi.

>_ Exercise

OrderService'ga holat o'zgartirish metodini qo'shing (faqat o'z chegarasi ichida).

  • UpdateStatus(id, status string) bool metodini yozing: agar order topilsa Status'ini yangilab true, topilmasa false qaytaring
  • "ord-1" yaratib, uni "shipped" holatiga o'tkazing va natijani (bool) hamda yangi Status'ni chop eting

Stuck? Reveal a hint to help you.

Hints (0/3)

Key Takeaway

Key Takeaway:

Har bir servis "bitta biznes qobiliyati" uchun javobgar bo'lishi kerak — boshqa servislarning ishini o'z ichiga olmasligi, ular bilan faqat aniq belgilangan aloqa (so'rov yuborish) orqali "gaplashishi" kerak.

NEXT UP

Service Boundaries Part 2: Data Ownership

OUTPUT

$ go run main.go
Kodingizni ishga tushiring

Service Boundaries

Servis chegaralari

Qo'shni ikkita davlatni tasavvur qiling: ularning chegarasi noaniq bo'lsa (qaysi hudud kimga tegishli — aniq emas), doimiy nizolar chiqadi. Chegara aniq chizilgan bo'lsa, har bir davlat o'z hududida mustaqil qaror qabul qiladi. Mikroservislarda ham xuddi shunday: har bir servisning chegarasi — u nima uchun javobgar, nima uchun EMAS — aniq belgilanishi shart.

Yaxshi chegara belgilashning oltin qoidasi — bitta biznes qobiliyati, bitta servis. "OrderService" faqat buyurtmalar bilan bog'liq ishni qiladi (yaratish, bekor qilish, holatini yangilash) — u hech qachon to'lovni HAQIQATAN amalga oshirmaydi (bu — PaymentServicening ishi) yoki ombordagi qoldiqni HAQIQATAN kamaytirmaydi (bu — InventoryServicening ishi).

example.go
package main

import "fmt"

// YOMON chegara: OrderService boshqa servislarning ishini ham o'zi bajaradi
type OrderServiceBad struct{}

func (s *OrderServiceBad) CreateOrder() string {
	// bu yerda to'lovni HAM, omborni HAM to'g'ridan-to'g'ri o'zgartiradi — chegara xira!
	return "buyurtma yaratildi, to'lov olindi, ombor kamaytirildi"
}

// YAXSHI chegara: OrderService faqat buyurtma holatini boshqaradi,
// boshqa ishlarni BOSHQA servislarga ISHONIB TOPSHIRADI (keyingi darslarda ko'ramiz)
type Order struct {
	ID     string
	Status string
}

type OrderService struct {
	orders map[string]*Order
}

func NewOrderService() *OrderService {
	return &OrderService{orders: make(map[string]*Order)}
}

func (s *OrderService) CreateOrder(id string) *Order {
	order := &Order{ID: id, Status: "pending"}
	s.orders[id] = order
	return order
}

func main() {
	svc := NewOrderService()
	order := svc.CreateOrder("ord-1")
	fmt.Println(order.ID, order.Status)
}

OrderServiceBad — chegarasi "xira": u o'z vazifasidan tashqariga chiqib, boshqa xizmatlarning ishini ham o'zi bajaradi. Bu — "Interface Design" kursida ko'rgan "interfeys ifloslanishi" muammosining servis darajasidagi ko'rinishi: agar to'lov mantig'i o'zgarsa, OrderServiceni ham o'zgartirish kerak bo'ladi, garchi u buyurtma bilan bog'liq hech narsa o'zgarmagan bo'lsa ham.

OrderService (yaxshi versiya) esa FAQAT buyurtma holatini (pending, paid, shipped...) boshqaradi. To'lov va omborni haqiqatan o'zgartirish — boshqa servislarning vazifasi, OrderService ular bilan faqat so'rov yuborish orqali "gaplashadi" (keyingi darsda ko'ramiz). Bu ajratish — kelajakda to'lov tizimini butunlay almashtirish kerak bo'lsa ham, OrderServicega tegmasdan qilish imkonini beradi.

>_ Exercise

OrderService'ga holat o'zgartirish metodini qo'shing (faqat o'z chegarasi ichida).

  • UpdateStatus(id, status string) bool metodini yozing: agar order topilsa Status'ini yangilab true, topilmasa false qaytaring
  • "ord-1" yaratib, uni "shipped" holatiga o'tkazing va natijani (bool) hamda yangi Status'ni chop eting

Stuck? Reveal a hint to help you.

Hints (0/3)

Key Takeaway

Key Takeaway:

Har bir servis "bitta biznes qobiliyati" uchun javobgar bo'lishi kerak — boshqa servislarning ishini o'z ichiga olmasligi, ular bilan faqat aniq belgilangan aloqa (so'rov yuborish) orqali "gaplashishi" kerak.

NEXT UP

Service Boundaries Part 2: Data Ownership