Methodology, Tản mạn, Uncategorized

Domain Drive Development (DDD) – First thought – Part 1

Nhan nhản trên Google có các câu hỏi đại loại như: so sánh giữa TDD (Test Driven Development) và DDD (Domain Driven Development), phương pháp nào tốt hơn? Rồi lại có BDD (Behavior Driven Development), CBD (Component-based Development) làm mình không khỏi confuse, tuy nhiên trong 1 phút suy nghĩ và cũng có được câu trả lời cho riêng mình. CDD mới là số 1. Cafein Driven Development. Người Việt ta thường có thói quen uống cafe, rảnh rỗi uống cafe, muốn thức khuya, uống cafe, vò đầu bứt tóc thì càng cần 1 tách cafe, vậy nên nó là tốt nhất.

TDD thì nghe nhiều làm nhiều (ko nhiều nhưng nói cho nó có vần). Vậy thì mình có thể tóm gọn nó trong 1 2 từ không? OK, TDD là 1 quy trình. Quy trình trong việc viết mã mà trước đó phải có unit test (automated). Mình không bàn sau về TDD, chỉ muốn nhấn mạnh đế chữ quy trình. Quy trình là gì: – Quy trình (規程 – Procedure) là trình tự (thứ tự, cách thức) thực hiện một hoạt động (#) đã được quy định, mang tính chất bắt buộc, đáp ứng những mục tiêu cụ thể của hoạt động (Wikipeadia). Nghĩa là cứ vậy mà triển khai, muốn viết code, cộng trừ nhân chia gì đó, hãy viết cùng với bộ test case.

business-plan-3

DDD thì mới nghe cách đây vài năm, lúc đó còn trẻ, còn đam mê với kỹ thuật, công nghệ này nọ, công nghệ, framework nào mới ra cũng muốn học, làm thử và trầm trồ, khen chê. Đến dạo gần đây, sau 1 thời gian cảm thấy không còn hứng thú với mớ công nghệ đó nữa (già rồi chăng, phần này làm biếng mô tả), lại nghe người trên nhắc nhiều đến domain, architecture của hệ thống. Chỉ cần nắm được domain và kiến trúc của hệ thống thì coi như làm chủ được nó. Mình đặc biệt thích thú về mảng kiến trúc, tuy nhiên trong bài này cùng bàn luận về domain 1 chút.

Domain là gì?

Domain, là kiến thức về business, hoàn toàn không liên quan đến công nghệ (technology). Vậy thì có ý nghĩa gì về mặt lợi ích khi 1 dân công nghệ lại chỉ đi học về chứng khoán, ngân hàng, bán lẻ,..?

Các bạn – dân công nghệ, có khi nào tự hỏi rằng khi làm việc trong 1 dự án (đặc biệt là outsourcing), thì chỉ biết cắm đầu làm, focus vào công nghệ, khi gặp trouble thì không thể tự giải quyết, đưa ra đề xuất mà toàn phải Q&A để nhờ giúp đỡ từ khách hàng. Rồi khi dứt áo ra đi, cái mà mình để lại cho người sau, có chăng chỉ là những tips và tricks, class diagram, troubleshootings cái environment quái quỷ. Rồi họ cũng chật vật như bạn, cho dù mình đi đâu đi chăng nữa.

Các bạn – lại là dân công nghệ, lần này có nhiệm vụ phát triển các hệ thống inhouse, cây nhà lá vườn (bự bự chút nha). Có khi nào khi được đưa vào project, liền mở source code ra đọc xem nó xài MVC hay MVVM, Database config ra sao, rồi khi nhận 1 task thì grep, debug hoặc hỏi người kế bên coi code trong class nào, mà hoàn toàn không hiểu được ngữ cảnh của công việc, bug văng từa lưa, nhiều khi cũng chẳng hiểu nổi thằng quái nào để lại đoạn “mật mã” này, làm gì với nó bây giờ. Có khi nào 1 dự án fail vì khách hàng không chịu làm acceptance, cả 2 phía dường như không hiểu được nhau, thôi đành chia tay, khách hàng cho anh phần đặt cọc, còn anh mất 1 khách hàng, tiền đâu nuôi đám dev bây giờ? Đuổi việc, giải thể công ty cho khỏe.

Sau 1 hồi vẽ ra những ngữ cảnh ở trên, chắc sẽ có nhiều người giật mình, và bắt đầu lo lắng, vậy tôi phải làm sao đây, chẳng lẽ đời đến đây là hết sao, sắp bị đuổi việc thật sao. Nhưng không sao, hãy bình tĩnh các bạn à, cùng nhau đi đến hết bài viết rồi hãy quyết định làm gì tiếp theo.

Deep dive into Domain and bring Domain belong/in to Project

Có 2 vế, thứ nhất là hãy học tập về domain mà cả team đang phát triển. Nếu một project tầm nhỏ và vừa thì chỉ cần các bạn developer năng động lên 1 chút, trong quá trình làm, phải document lại những kiến thức và hiểu biết của mình về 1 nghiệp vụ nào đó và cùng share cho cả team, mỗi người đảm nhận 1 module, nghiệp vụ, sau này có thể hoán đổi vị trí cho nhau để hiểu sâu hơn về phần khác. Keyword ở đây chính là: Knowledge Base. Nghĩa là mọi thứ đừng nên để trong đầu mỗi người, mà phải được viết ra, hiện hữu trên giấy tờ, tài liệu, đem nó vào 1 chỗ shareable cho toàn team như wiki hoặc 1 shared folder nào đó. Đến một ngày, kho kiến thức của cả đội (về cả nghiệp vụ và kỹ thuật) sẽ ngày càng hoàn thiện, mọi người ai cũng happy vì khi đề cập đến 1 vấn đề nào đó thì có thể hình dung ra, giải quyết nó hoặc đưa ra giải pháp cho khách hàng. Ai cũng được tăng lương, ngày làm 8 tiếng.

Nếu một dự án quá bự, các bạn developer phần không có thời gian để tìm hiểu tường tận, phần phải vò đầu với các công việc về mặt technical và integration thì hãy chào đón các thành viên mới cho đội của mình, các BA (Business Analyst). BA là người có đầu óc phân tích về nghiệp vụ rất tốt, vì họ được đào tạo các kỹ năng để làm chuyện đó. Đứng giữa khách hàng và các developer chính là các vị BA. Họ luôn sẵn sàng lắng nghe và truyền tải thông điệp giữa 2 phía. (Lưu ý ở đây là cả 2 phía chứ không phải chỉ là người truyền tải requirement từ khách hàng đến các dev, các dev ở đó có la ó cũng mà trời cao cũng không thấu là không được, cần phải nghĩ đến chuyện hòa hợp giữa business aspect và technical aspect). Trách nhiệm chính của các ông/bà BA là phân tích requirement khách hàng nói bằng ngôn ngữ tự nhiên, distill (chắt lọc) và modeling (mô hình hóa) thành dạng requirement mà dev có thể hiểu và thực hiện được.

Đó là phần ý tưởng (idea), còn đây là phần hiện thực nó. Sẽ gộp chung cho cả 2 phía, Dev và BA. DDD chính là chìa khóa. Bất kể là Dev hay BA thì cũng nên biết đến phương pháp này để làm cho cuộc sống happier.

DDD là gì, nó sẽ làm được những gì, so sánh, kết hợp với các xDD khác như thế nào, mời các bạn đón xem ở phần 2.

edwardthienhoang.

Advertisements

4 thoughts on “Domain Drive Development (DDD) – First thought – Part 1”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s