Trong phần trước  chúng ta được được giới thiệu về Domain Driven Design và cũng hiểu rằng kiến trúc tập trung vào phần core domain. Như một cách tiếp cận truyền thống vào dự án, lập trình viên thì họ sẽ chỉ nghĩ tới các lớp, method, các pattern,thuật toán, cách thư viên và làm sao để cho source code cấu trúc tốt, có tính mở rộng và dễ maintain. Họ muốn nhìn các đối tượng và các liên hệ giữa chúng, nghĩ đến những thứ như kế thừa, đa hình và OOP… Khi trao đổi thì luôn diễn tả mọi thứ theo hướng đó nên nó gây khó hiểu cho những người không hiểu rõ về kỹ thuật. Do đó, những chuyên gia về Domain họ không hiểu những khái niệm về framework, persistence và trong nhiều trường hợp họ không hiểu về cơ sở dữ liệu vì đơn giản nó không phải là chuyên ngành của họ

Theo một cách tiếp cận truyền thống thì lập trình viên họ sẽ tự design và thiết kế hệ thống thông quan việc trạo đổi thông tin với Domain Expert. Nhưng chuyện gì xảy ra nếu họ hiểu nhầm và thiết kế theo một hướng không đúng?. Lúc đấy chắc chắn sẽ lại phải thiết kế lại từ đầu và thậm trí tạo nên sự chắp vá, source code phình to dẫn đến khó maintain và mở rộng.

DDD đã giúp chúng ta giải quyết vấn đề này bằng cách: lập trình viên và Domain Expert sẽ cùng nhau thiết kế xây dựng domain. Do đó, chúng ta cần phải xây dựng một ngôn ngữ chung để cho Domain Expert và lập trình viên có thể hiểu và trao đổi với nhau được.

Trước khi bắt đầu mỗi dự án thì nhóm phát triển và Domain Expert sẽ phải ngồi với nhau và cùng nhau xây dựng một ngôn ngữ chung. Định nghĩa ra các khái niệm như hệ thống này dùng để làm gì, trong hệ thống thì có các đối tượng và thưc thể nào. Ví dụ hầu hết hệ thống đều có User. Chúng ta phải định nghĩa rõ ràng ra User ở đây là những ai và sẽ có các thông tin và thuộc tính nào ? Nếu trong hệ thống quảng cáo thì có thể họ là Consultant thì ta có thể đổi tên User thành Consultant cũng được. Việc này cần được thống nhất giữa team phát triển và Domain Expert.

Ubiquitous language (UL) rất quan trọng trong DDD, nó không chỉ là công cụ trao đổi trong nhóm mà kể cả trong source code nó gần như là các khái niệm, tên gọi được thống nhất chung giữa lập trình viên. Nên chỉ cần nhìn vào tên của class hoặc package chúng ta cũng có thể hiểu phần này đang làm về cái gì.

Sau khi nhóm phát triển và Domain Expert có thể thống nhất với nhau một ngôn ngữ chung thì dựa vào đó họ có thể cùng nhau xây dựng Domain, context map. Tất cả đều được dựa trên các định nghĩa và khái niệm trong UL.

UL cũng rất là hữu ích khi một lập trình viên họ tham gia vào một dự án đang chạy. Khi đó, họ sẽ phải đọc UL đầu tiên và dựa vào đó thì sẽ hiểu được về hệ thống có tính năng gì và gồm những chức năng gì ? Sau đấy họ nhìn vào domain design để hiểu hơn về nghiệp vụ của hệ thống, giúp họ dễ dàng tiếp cận với source code đang chạy. Nói cách khác UL cũng giống như một chuẩn về document cho dự án, giúp cho một thành viên dễ dàng hơn trong việc tiếp cận một dự án mới

Sau đây là một ví dụ về hệ thống BBS:

1. Yêu cầu của dự án

User story 1: User can view article list with email & created date without login in BBS

User Story 2: User can view article content and mail address of post creator

User story 3: User can create article in BBS

User story 4: User can log into BBS with mail address and password

User story 5: User can create article without inputting mail address if user is under login status

User story 6: User can register new user

Bên trên là một ví dụ về yêu cầu xây dựng một hệ thống BBS đơn giản và nó được chia thành 6 user story.

Mỗi user story sẽ miêu tả mong muốn của khách hàng về hệ thống gồm có nhưng tính năng và chức năng như thế nào

2. Xác định những đối tượng mà cần đưa vào UL

Khi nhìn vào user story bên trên thì nhóm phát triển sẽ hỏi và thắc mắc:

• BBS là gì ? Đây là hệ thống như thế nào ?
• User ở đây là những ai ? Ai là người sẽ dùng hệ thống ? Có những thông tin gì ?
• Article là gì ? Có những thông tin như thế nào

Do đó lập trình viên và Domain Expert cần ngồi cùng với nhau và định nghĩa rõ ra BBS, User và Article là gì ? Cách đặt tên như thế nào cho hợp lý ? Và kết qủa cuối cùng sẽ được định nghĩa trong UL

3. Định nghĩa UL

 

Name	Description
BBS	System for share information of company trip between company A original & technology
Guest	Staff in company Guest can view article list & detail without login
User	Staff in company User information name company ( 2 options = company A original & technology ) email password User login with email format = “@a-technology.com” or “@a-original.com” & password
Article	Information of company trip is shared by staff Article information title content createdDate

 

Bảng bên trên chính là một format của UL và nó được tạo bởi nhóm phát triển và Domain Expert. Dựa vào những thông tin này, giờ đây khi bạn đọc lại các user story bên trên thì sẽ hiểu được ticket này yêu cầu làm gì và làm như thế nào.

Sau khi chúng ta định nghĩa ra UL thì bước tiếp theo là sẽ cũng nhau xây dựng Domain Design cho dự án