DDD - Bounded Context Là Gì ? - DEV Community

Bounded Context (BC) là gì?

BC là một trong những nguyên tắc DDD khó giải thích nhất, nhưng có lẽ nó là quan trọng nhất, bởi vì sẽ không thể làm DDD mà không có BC. Vì vậy, phải hiểu cách xác định BC trước khi thực sự tìm hiểu đến với Aggregate Roots, Aggregates, Entities and Value Objects. Một Context mang ý nghĩa là một phòng ban trong một công ty sẽ đảm nhận một trách nhiệm cụ thể.

  • Bộ phận kinh doanh sẽ hỗ trợ thương mại, tác nghiệp kinh doanh.
  • Bộ phận R&D sẽ chịu trách nhiệm nghiên cứu phát triển sản phẩm mới, nghiên cứu gia tăng tính năng, chất lượng sản phẩm hiện hữu, xây dựng và triển khai các dự án kinh doanh, công trình, sản xuất,...

Phong, một developer tại công ty BSS. Phong làm việc trong bộ phận CNTT. Bộ phận CNTT là một BC . Nó có trách nhiệm xử lý mọi thứ liên quan đến CNTT trong công ty. Nhân, một kế toán tại cùng công ty. Nhân làm việc trong phòng Kế toán. Bộ phận kế toán xử lý mọi thứ liên quan đến kế toán, bao gồm cả bảng lương. Cả hai đều có trách nhiệm rất chính xác và ranh giới của họ là khá rõ ràng.

Về thực tế 2 người họ ở các văn phòng khác nhau. Họ có tổ chức nội bộ của riêng họ, quy tắc nội bộ của riêng họ, nhân viên, v.v.

  • Phong không vào văn phòng của Nhân để sửa đổi bảng lương tăng lên x2, thưởng x4.
  • Nhân không đến chỗ làm việc của Phong để sửa đổi code của Phong cho sai logic.

2 người họ có thể làm những điều trên nhưng đó sẽ gây ảnh hưởng và dẫn đến hậu quả nghiêm trọng. Nếu Nhân tìm thấy một lỗi trong phần mềm kế toán (được phát triển nội bộ), Nhân nên gọi cho bộ phận CNTT để xử lý nó. Phong muốn tăng lương nên thương lượng lại lương với giám đốc công ty.

  • Nhân không thể cài đặt PhpStorm và bắt đầu code Laravel (là một framework PHP hiện đại, design pattern xịn, code rất là đẹp). Đó không phải là trách nhiệm của Nhân và Nhân không biết làm thế nào để làm điều đó, ngay cả khi Nhân biết rằng PhpStorm (IDE rất tốt cho PHP developer) là chương trình được Phong hay sử dụng để viết code. Trên thực tế, PhpStorm sẽ là một phần mềm rất lạ trên máy tính của kế toán viên. Tương tự thì các tập tin về bảng lương, biên chế hoặc hóa đơn cũng không có trong bộ phận CNTT.

  • Nhưng tất nhiên, khi Phong gặp vấn đề liên quan đến bảng lương, Phong có thể yêu cầu Nhân xem xét nó. Cả hai đều tôn trọng ranh giới của nhau và hành động theo trách nhiệm của họ. Nhưng bộ phận CNTT tự tổ chức thành 2 nhóm: nhóm phát triển phần mềm và nhóm quản trị.

  • Nhóm đầu tiên thực hiện các tính năng và sửa lỗi (Developer: Đa số là sinh viên vừa ra trường, làm được vài dự án khủng khi bảo vệ luận văn, đa số không biết design principle, SOLID, DRY, KISS là gì, phận mãi làm cuder, lương đủ mua mì gói sống qua ngày ).

  • Nhóm thứ hai xử lý các máy chủ data(DBA : Database Administrator, mấy ông này làm việc ít, đa số thời gian là thảnh thơi trong công ty nhưng lương tháng lại cao ngất ngưỡng).

Mỗi nhóm là một Bounded Context. Họ có trách nhiệm riêng và ranh giới rõ ràng. DBA không viết code Laravel PHP và Phong không tự ý cài đặt lại cấu hình máy chủ. Mọi người hành động theo trách nhiệm của họ và trong ranh giới của họ.

Vì vậy, bộ phận CNTT là một BC. Phong là một phần của mô hình của nó. Trong thực tế thì mọi thứ có ý nghĩa như (developer, máy chủ, v.v.) là một phần của BC và nó phải nhất quán bên trong nó (developer nên viết phần mềm và không được đòi hỏi về quản lý hóa đơn).

Điều tương tự là Nhân không có vị trí trong bộ phận CNTT và Nhân không nên xử lý bất cứ điều gì liên quan đến bộ phận CNTT. Nhân là một phần của Kế toán BC. Nhân có thể đến bộ phận CNTT chơi nhưng sau đó Nhân chỉ là một người bạn đi ngang qua, Nhân không có ý nghĩa gì với bộ phận CNTT và không ai mong Nhân sẽ ở lại viết code Laravel PHP hay fix bugs hộ hoặc đóng vai trò là developer.

Phong có thể phải lòng Nhân và dành một chút thời gian trong văn phòng của Nhân, nhưng điều đó không khiến Phong trở thành một kế toán viên.

Có khá nhiều những BC độc lập và chúng không trùng nhau. Hơn nữa, nếu một đối tượng từ một BC (X) chuyển sang BC (Y) khác, điều đó không có nghĩa là bây giờ nó là một phần của sau này, nó được xem giống như một đối tượng đơn giản không có ý nghĩa đối với Y.

2 người làm việc gần như độc lập nhưng làm thế nào họ có thể làm việc cùng nhau không? Nghĩa là bộ phận CNTT và Kế toán phải làm việc cùng nhau theo thời gian. Họ làm điều đó bằng cách nói chuyện với đúng người (người thứ 3 :) ).

  • Khi Nhân cần một tính năng phần mềm mới, Nhân có thể nói với Phong, nhưng người quản lý của Phong (là Dự) cuối cùng sẽ quyết định xem những tính năng nào sẽ được thêm vào.

  • Dự là người tiếp nhận cuộc nói chuyện khi Nhân muốn các tính năng mới hoặc thậm chí để sửa một số lỗi. Dự là người quản lý bộ phận CNTT và giao tasks cho Phong (hoặc bất kỳ ai khác trong bộ phận CNTT) sẽ phải làm gì tiếp theo.

  • Nhân không thể bỏ qua Dự xem như người vô hình được vì đây là quy tắc trong bộ phận CNTT: Dự là người sẽ ra quyết định. Nhân phải trình bày ý tưởng của mình cho Dự nghe, nếu không thì yêu cầu sẽ bị từ chối.

  • Nếu các yêu cầu không có ý nghĩa đối với bộ phận CNTT như bao cafe Phúc Long hay bánh mì 7-eleven, yêu cầu sẽ bị từ chối. Dự là Anti Corruption Layer của CNTT BC. Không yêu cầu gì có thể tự ý thông qua nếu chưa được sự đồng ý của Dự và những yêu cầu gì nếu đã thông qua, nó sẽ được chấp nhận để phát triển thêm cho phù hợp với tổ chức nội bộ của bộ phận CNTT.

Từ khóa » Nguyên Lý Ddd