Bài viết đươc cung cấp bởi Mr Thành Nguyễn - http://bit.ly/2e8siZX.

Ở BÀI TRƯỚC (http://bit.ly/why-ddd) sau khi Start with why thì chúng ta đã có lý do cho việc tìm hiểu về Domain Driven Design rồi nên sang tới bài này chúng ta sẽ tiếp tục với câu hỏi Domain Driven Design là cái gì? Câu trả lời thì cũng không quá đơn giản và dễ dàng nhưng cũng không đến mức quá cao siêu và phức tạp như cách mà những chuyên gia trình bày trong các quyển sách viết về Domain Driven Design.

Trước khi đưa ra câu trả lời thì mình có một bức xúc muốn bày tỏ đó là mình rất ghét mấy thằng Tây viết sách về IT ( nó là ghét bọn Tây đơn giản là vì chưa có thằng Ta nào viết sách về mấy món này toàn Tây viết chứ không phải phân biệt gì cả ), cuốn sách nào cũng dài đến vài trăm trang mà thực chất thông tin có giá trị cô đọng lại chỉ có được đến vài trang và nhiều lắm là hai ba chục trang. Thời đại thông tin bay nhanh hơn tên lửa thì lấy đâu ra thời gian mà ngồi gặm nhấm hàng đống thông tin rác rưởi cố tình bôi vẽ ra cho nhiều để bán sách kiếm tiền và lấy danh tiếng. Thế nên các bạn lưu ý đừng mất thời gian vô bổ vào việc đọc sách một cách tuyến tính line by line đi từ đầu đến cuối, hãy nhớ rằng định luật Pareto ( hay còn gọi là định luật 80/20) luôn luôn đúng. Sách của bọn Tây di mọi rợ viết chỉ có nhiều lắm 20% thông tin là valuable còn lại toàn là thứ vẽ rắn thêm chân nên khi đọc sách chúng viết tốt nhất là chọn cách nhảy dù vào giữa khu rừng rậm và phải luyện cho mình kỹ năng lùng sục, thế nào rồi chúng ta cũng sẽ lôi ra được từ trong đó vài chục em thổ dân xinh tươi trong tình trạng nude sẽ phản ánh đúng bản chất trần trụi của vấn đề. Bây giờ mình sẽ show cho các bạn vài em như thế có thể giúp các bạn có cái nhìn khái quát gần gũi nhất về Domain Driven Desgin.

Để tránh có cái nhìn sai lạc trước tiên phải xóa bỏ ngay một số hình dung sai lầm thường thấy về DDD là DDD là một công nghệ mới hay là một Framework mới. DDD không liên quan gì đến công nghệ hay Framework là những thứ thuộc về tầng vật lý ( Physical View ) mà nó là một khái niệm thuộc về tầng logic ( Conceptual View ) khi chúng ta xây dựng một hệ thống phần mềm. Cụ thể hơn nó là một Design Pattern và hơn nữa đây là Design Pattern ở cấp độ kiến trúc của hệ thống Architectural Pattern , chúng ta cần rõ điều này để phân biệt với các Design Pattern nổi tiếng ở cấp độ class được viết trong sách của bọn bè lũ bốn tên ( Gang of Four ) . Nó cung cấp một cấu trúc thực hành ( Structure of practice ) và các thuật ngữ ( terminology ) giúp cho việc ra các quyết định thiết kế được hiệu quả hơn. Và vì nó tỏ ra hổ báo như thế nên chúng ta rà soát lại kiến trúc ngôi nhà mà nó vẽ ra một lần nữa xem tròn méo thế nào.

Ở bài trước cũng đã nêu ra kiến trúc này rồi nhưng chưa đi sâu vào chi tiết vê sự khác biệt giữa mô hình 3 lớp truyền thống với kiến trúc của DDD. Theo mô tả của DDD thì các tầng của nó có vai trò như sau:

• User Interface Layer: làm nhiệm vụ biểu diễn thông tin trực quan cho user và dịch các user command ( ở đây chúng ta có thể hiểu là các event xảy ra trên giao diện khi được trigger ( nhấn nút trên các UI input control ) là các sẽ được dịch thành các command xử lý ở các tầng dưới.

• Application Layer: Tầng này được thiết kế khá mỏng ( thin ) với ít logic xử lý chỉ để làm nhiệm vụ coordinate các Activity của Application và không chứa Business Logic, nó không chứa state của các Business Object mà chỉ chứa state của Application Task Progress. Chúng ta có thể hình dung phần này gần giống với các Controller trong mô hình MVC chỉ làm nhiệm vụ forward các task đến nơi cần xử lý.

• Domain Layer : Đây là trái tim của ứng dụng ( Business Software ), các state của Business Object đều nằm ở đây. Việc lưu trữ ( persistence ) các Business Object và các state của nó được chuyển giao cho tầng Infrastructure ở dưới.

• Infrastructure Layer : Đóng vai trò cung cấp thư viện ( supporting libraries )cho các tầng khác. Nó cung cấp cơ chế giao tiếp ( communication ) giữa các Layer với nhau, cũng như cung cấp các chức năng khác như lưu trữ ( persistence ) các Business Object của tầng Domain.

Theo mình thì 3 tầng phía trên là khá dễ hiểu vì nó khá tương đồng với mô hình 3 lớp truyền thống, chỉ có tầng Infrastructure là dễ gây confused nhất cho mọi người. Lý do không phải vì sự phức tạp của nó mà do cách dùng từ của thằng cha Eric Evans làm cho người ta dễ hiểu nhầm. Một trong những lý do làm mình ghét mấy thằng Tây viết sách ở trên là vì ngoài việc viết dài vô bổ còn một lý do khác nữa là việc sính dùng từ cũ theo nghĩa mới một cách tùy tiện. Trong ngành IT có một tình trạng hết sức khó chịu đó là việc không có sự chuẩn hóa khái niệm một cách rõ ràng nên cùng một từ thôi nhưng ở nơi này nơi kia được các ông khác nhau sử dụng với nghĩa khác nhau vì ông nào cũng không muốn” tạo dấu ấn riêng” ta đây cũng đều là anh hùng anh bá cả nên cứ phải chơi những thứ mới lạ nó mới độc đáo, chẳng hạn như ông java thì dùng package còn ông .Net thì dùng namespace, 2 cái này về bản chất chẳng khác mẹ gì nhau ? Chẳng qua vì các bố muốn tỏ ra khác biệt không muốn lặp lại của thằng khác nên “sáng tạo” ra khái niệm mới, chỉ khổ anh em nào lúc mới bắt gặp mấy “ từ mới” lại tốn thời gian để tìm hiểu xem cái thằng What The Fuck này nó là cái gì.

Tương tự ngày xưa nói Data Mining bây giờ có thêm Big Data rồi thì lại đẻ ra khái niệm Data Analytic ở một cái seminar mình hỏi Data Minning với Data Analytic khác gì nhau thì đến cả một bác Associate Professor của 1 trường đại học ở Mẽo cũng dek phân biệt được rõ ràng. Luôn có những tình huống mà từ mới được sáng tạo ra một cách vô thức hoặc có ý đồ do bản chất thương mại và marketing đã gây ra nhiều khó khăn về mặt technical cho việc hiểu đúng đắn các khái niệm trong ngành IT.

Ở một chiều hướng khác là các từ giống nhau được dùng rất đa nghĩa nhất là các từ như platform, infrastructure thì luôn ở trong tình trạng loạn cào cào mỗi cụ lại chế ra một nghĩa.

Trong mô hình ba lớp cũ thì những cái gì không thuộc về xử lý liên quan đến nghiệp vụ sẽ được xếp chung vào 1 giỏ gọi là cross-cutting concern và không có tài liệu nào đề cập đến cái gọi là infrastructure cả. Có một truyện ngược đời kiểu sinh con rồi mới sinh cha thế này. Sau khi Domain Driven Design và đưa ra Infrastructure Layer thì một số đồng chí khi so sánh giữa mô hình 3 lớp cũ với DDD lại dùng chính khái niệm này để mô tả về mô hình 3 lớp như trong cái hình này.

Quả thực là vấn nạn do các chuyên gia tạo ra trong ngành IT không biết bao nhiêu mà kể, thế nên để hiểu đúng vấn đề thì chính chúng ta phải chủ động đãi cát tìm vàng còn đâu bọn chuyên gia chém thế nào thì makeno thôi. Thường thì Infrastructure được hiểu theo nghĩa là liên quan nhiều đến yếu tố vật lý phần cứng ví dụ như Infrastructure as Service của Amazon cung cấp Cloud service ở mức độ phần cứng chẳng hạn còn ở đây Infrastructure lại được hiểu theo nghĩa là hạ tầng phần mềm nhưng lại chỉ là hạ tầng phần mềm trong scope của ứng dụng thôi chứ không được hiểu theo scope rộng là infrastructure của toàn bộ hệ thống ( bao gồm hệ điều hành, platform etc… )

Chúng ta có thể hiểu cho đơn giản là phần Infrastructure chính là phần các phần cross-cutting concern trong mô hình 3 layer cũ như logging, security, ultility etc… cộng thêm với phần data persistence vốn dĩ thuộc về tầng Data Access Layer cũ nhưng được tách biệt hoàn toàn ra khỏi phần Business Logic để tăng tính stable cho phần Domain và nó sẽ độc lập hơn với Datasource ( chẳng hạn khi chúng ta thay đổi định lưu trữ như từ database sang file hay ngược lại thì phần Domain cũng sẽ không phải thay đổi ). Theo mình nghĩ thì sở dĩ phần này được gọi Infrastructure vì khi tư duy rằng Domain là trái tim của ứng dụng, cần phải focus vào logic của nghiệp vụ thì các công việc khác không được xem là quan trọng sẽ xếp vào công việc điếu đóm bếp núc nên nó sẽ được gọi là Infrastructure code.

Đến đây thì chúng ta sẽ thấy kiến trúc của Domain Driven Design tuy mới nhìn có vẻ lạ nhưng thực ra là cũng quen, chỉ đơn giản là nó customize lại mô hình kiến trúc 3 lớp cho linh hoạt ( flexible ) hơn và mịn hơn mà thôi ( tăng tính granularity của thiết kế ). Tính linh hoạt này được tạo ra từ hệ quả của việc tái tổ chức lại các layer từ mô hình ba lớp, nó thể hiện ở data flow và control flow giữa 2 mô hình.

Chúng ta có thể thấy là trong mô hình 3 lớp thì tầng trên sẽ phụ thuộc trực tiếp vào tầng dưới nên không thể truy cập dữ liệu một cách trực tiếp từ tầng Presentation sang tầng Data Access Layer mà không thông qua tầng Business Layer. Còn mô hình DDD thì từ tầng User Interface nếu muốn lưu cái gì đó vào trong database chẳng hạn nó có thể gọi trực tiếp xuống tầng Infrastructure để làm được việc đó. Rõ ràng là trong kiến trúc DDD thì tính lose coupling được đảm bảo tốt hơn. Có thể hình dung một cách trực quan là mô hình 3 lớp giống như một ngôi nhà 3 tầng chỉ có cầu thang bộ, và việc di truyển giữa tầng một và tầng 3 cần đi qua sàn tầng 2, trong khi mô hình DDD giống như ngôi nhà 4 tầng có lắp thêm thang máy, chúng ta có thể di chuyển đến các tầng khác nhau một cách tự do hơn.

Vậy là tạm thời giới thiệu song phần kiến trúc, bây giờ chúng ta sẽ tiếp tục đi sang phần xây dựng. Để xây dược nhà thì tất nhiên là cái chúng ta quan tâm phải là những viên gạch. Domain Driven Design cũng thiết kế một số viên gạch ( Building Block ) như thế và chúng được gọi là các Domain Model.

Khi chúng ta đọc truyện kiếm hiệp hay xem phim chưởng chẳng hạn chúng ta sẽ thấy xuất hiện một loạt các “thuật ngữ chuyên môn” từ vĩ mô như võ lâm, giang hồ, tới khái niệm ở cấp vi mô như bí kíp võ công, khẩu quyết etc.. tất cả những cái đó đều là các domain object theo đúng nghĩa đen của một domain là “truyện kiếm hiệp” , những thuật ngữ này là những khái niệm chung nhất để phân loại các nhóm đối tượng trong domain vào 1 cái rọ chung để cơ cấu nhận thức của chúng ta dễ nhận diện và quản lý. Chẳng hạn bí kíp võ công thì có nhiều loại bí kíp cụ thể khác nhau như Cửu Âm Chân Kinh, Quỳ Hoa Bảo Điển, Càn Khôn Đại Na Di etc… nhưng chúng đều có đặc điểm chung là truyền dạy các kiến thức để luyện được võ công thượng thặng. Khi chúng ta làm design với domain model chúng ta cũng phải thiết kế ra các nhóm pattern chung cho một lớp các đối tượng như thế để dễ quản trị và implement. Về cơ bản thì các Domain Model trong DDD gồm có các loại cụ thể như sau: Entity, Value Object, Aggregate, Domain Event, Service, Repository và Factory.

Hiện tại chúng ta đang nói về thiết kế nhưng thiết kế chỉ là phần không sờ mó nắn bóp được nên rất khó hình dung nên mình xin lấn sang một chút phần implementation. Chúng ta cứ hình dung trong một domain là lĩnh vực quân sự thì có rất các đơn vị thuộc binh chủng khác nhau như hải lục không quân, trong đó có nhưng binh sĩ và sĩ quan từ cấp binh bét đến cấp tướng, nhưng dù là binh bét hay đại tướng đại soái gì thì các đồng chí ấy đều là người cả mà thôi, chỉ khác là chúng ta khoác lên người họ những bộ quân phục với cầu vai phù hiệu khác nhau và họ dược huấn luyện trang bị các kỹ năng khác nhau. Tương tự như thế thì mấy thằng Enity, Value Object etc… khi được implement để xây dựng ứng dụng chúng cũng được implement thông qua các class Java hay C# etc.. tùy thuộc vào ngôn ngữ mà bạn lựa chọn. Domain Driven Design là loại thiết kế hướng đối tượng nên việc implement thiết kế này cũng gắn chặt với lập trình hướng đối tượng OOP nên muốn dễ hiểu thì chúng ta cứ map các khái niệm của pattern từ phần thiết kế sang các khái niệm của OOP là hiệu quả nhất. Bây giờ chúng ta sẽ xem xem giữa tướng và tá, lính công binh và lính hải quân khác nhau thế nào.

• Entity: Là một object mà nó được định nghĩa không phải tập thuộc tính của nó mà bởi tính liên tục ( continuity) và tính định danh ( identity ) của nó. Có vẻ là càng giải thích thì lại càng thấy phức tạp vì lại đẻ thêm ra mấy khái niệm mới rắc rối. Đấy là cách mà bọn học sĩ cao siêu nó giải thích còn mình sẽ lấy ví dụ bình dân trong thực tế cho mọi người dễ hiểu. Khi bạn book vé máy bay thì các bạn hàng không sẽ cấp cho bạn một chỗ ngồi và chỗ ngồi của bạn trên vé phải là duy nhất ( vì nếu 2 người có cồng một số ghế thì nhiều khả năng là sẽ có 1 em hoa hậu nào đó đi cùng chuyến với bạn sẽ phải ngồi lên lòng bạn nếu nhà tàu không đổi cho bạn 1 vé khác. Và vé của bạn được duy trì cho đến khi chuyến bay kết thúc, cái ghế bạn ngồi sẽ được release cho một lần book khác, cái này chính là continuity hay life cycle của object ( cái vé ). Qua đó có thể thấy Enity chẳng có gì khác hơn là một Object thông thường chúng ta vẫn sử dụng trong ứng dụng thông thường, ngoài việc nó phải đảm bảo tính duy nhất ( Uniqueness ) của mình, phân biệt được nó với những cái khác và chương trình phải quản lý được cái Indentity của nó.

• Value Object : Quay lại với ví dụ về vé máy bay ở trên, ta cũng lấy luôn ví dụ đó nhưng trong một context khác. Thường thì các hãng hàng không đều có số ghế ở trên vé cho khách trước khi lên máy bay những vẫn có 1 số hãng hàng không lại không yêu cầu điều này, thường là các hãng giá rẻ chẳng hạn như Southwest Airlines thì chẳng thèm quan tâm đến số ghế, vé nào cũng như vé nào, cứ có vé là a lô xô nhảy lên máy bay thích ngồi đâu thì ngồi, khi đó cái vé máy bay sẽ không còn là Entity nữa mà nó là Value Object. Value Object thì không cần định danh duy nhất ( conceptual indentity ) , nó là object được tạo ra để cung cấp các giá trị cho chương trình. Một ví dụ cụ thể hơn giúp chúng ta dễ hiểu vai trò của Value Object là khi chúng ta gặp một bài toán cần lưu trữ lượng tiền thanh toán giao dịch, chúng ta sẽ tạo ra một object là Money chưa các thuộc tính là value ( số tiền ) và currency ( để lưu đơn vị tiền tệ là USD hay JPY ). Rõ ràng là nếu bạn được trả cho 1 đồng dollar thì bạn đâu có quan tâm xem nó là đồng đô la sản xuất ngày nào, nhà máy nào sản xuất , cái bạn quan tâm là giá trị của nó và các đồng 100 dollar thì đều giống nhau, đồng nào cũng tiêu được cả, đâu cần phân biệt chúng làm gì.

• Service: Khi chúng ta phân tích domain và cố gắng định nghĩa các object tạo thành model chúng ta nhận thấy rằng có một số khía cạnh của domain sẽ không map được với object. Cụ thể là object thường có trạng thái ( state ) và hành vi ( behavior ) thao tác ( manipulate ) trên các state đó. Các danh từ thường được map với các object và các động từ sẽ map với các behavior của object, điều này là rất tự nhiên. Tuy nhiên trong các lĩnh vực cụ thể ( domain ) có những action cụ thể mà động từ mô tả nó lại không thuộc về riêng một object nào cả. Chúng ta không thể implement nó thành các behavior của Entity hay của Value Object, đưa thêm các Behavior như vậy vào trong Entity hay Value Object có thể làm hỏng các object đó. Chẳng hạn như việc chuyển tiền giữa 2 account thì chức năng chuyển tiền sẽ thuộc về account nhận hay account gửi? Rõ ràng là nó liên quan đến cả 2 và chúng ta không thể đặt nó ở cả 2 nơi được. Nhưng vì chúng ta đang xây dựng ứng dụng bằng cách thiết kế hướng đối tượng và lập trình hướng đối tượng nên chúng ta cần sử dụng một object cho tình huống này. Đó là lý do cho việc tồn tại của Service, bản chất nó là một object không có các internal state mà chỉ thực hiện các behavior, service là một cách đóng gói các khái niệm, gộp các chức năng phục vụ cho các Entity và Value Object khác. Nếu Entity hay Value Object được map với Thing ở ngoài thế giới thực thì Service sẽ map với Operation, Activity ở ngoài thế giới thực.

• Aggregate: Blog của sotatek có nhúng Social Plugin của facebook ở dưới mỗi bài viết nên mọi người có thể like vào comment vào bài viết này. Mình giả sử một cách lạc quan tếu rằng bài này rất hot nên có khoảng 1000 Like và 200 comments. Đang hý hửng thì đùng một cái có một đồng chí nhảy vào dội cho gáo nước lạnh comment là “Viết cái gì mà ngu thế?”. Tức mình nên mình xóa béng đi cái bài này thế là hơn 1000 Like và 201 comment cùng với Tag ở dưới cũng đi tong theo luôn. Các bạn nhận thấy sự gắn bó chặt chẽ giữa bài viết với các Like và Comment rồi chứ. Bài viết này là một Entity còn các Like và Comment là những Entity khác hoặc cũng có thể là Value Object , chúng nằm trong một mối quan hệ kết tập gọi là Aggregate. Tập hợp bài viết, các comment, tag và like tạo thành 1 Aggregate và có 1 thành phần duy nhất trong đó đóng vai trò là Aggregate Root sẽ mang một global indentity với bên ngoài, ở đây bài viết này chính là Aggregate Root, còn các object khác như Like hay Comment sẽ được xác định theo Aggregate và mỗi object sẽ có một local indentity. Aggregate là nó là Domain Pattern dùng để định nghĩa Ownership và Boundries, Khi nào đụng đến 2 thứ này như ví dụ trên chúng ta sẽ lôi nó ra dùng.

• Factory: Như chúng ta biết trong lập trình hướng đối tượng khi khi một client object muốn khởi tạo một object khác trong quá trình xử lý dữ liệu của nó sẽ gọi constructor của object đó và truyền vào đó một vài tham số. Nhưng vì các Entity và Aggregate có xu hướng trở nên phức tạp nên công việc tạo contructor cho một Aggregate Root là một công việc thuộc loại to tay ( laborious ) đồng thời nó cũng đòi hỏi phải hiểu rõ về cấu trúc bên trong của object và các mối quan hệ ( relationship ) bên trong object đó cũng như các luật áp dụng cho chúng, việc này dẫn tới hệ quả là nó phá vỡ tính đóng gói của các domain object như Aggregate. Thế nên công việc này sẽ được chuyển giao cho Factory. Đây là cách áp dụng Design pattern “Factory” khá nổi tiếng và phổ biến vào kiến trúc chung của DDD.

• Repository: Cũng giống như Factory thì Repository là một design pattern đã xuất hiện từ trước khi có Domain Driven Desgin, chỉ khác là thay vì trước đây là một anh thợ hồ dạo gặp nhà nào thuê là em vào xây thì nay em được bác thầu xây dựng đưa về đội lập thành đội xây chuyên nghiệp cùng với các anh em khác trong đại gia đình DDD mà thôi. Repository làm đóng vai trò trung gian giữa Domain và Data Mapping Layer ( có thể coi là một bộ phận của Infrastructure Layer trong kiến trúc mô tả ở đầu bài ), nó có nhiệm vụ xử lý persitent process tức là lưu trữ data lâu dài, có thể là lưu các các object xuống database hoặc file cũng như lấy các dữ liệu đã được lưu trong database hay file ra bộ nhớ thành các object để xử lý. Nói như vậy thì chúng ta cảm thấy có một sự lẫn lộn giữa khái niệm quen thuộc là DAO ( Data Access Object ) với Reposiotory. Đúng là 2 thằng này rất dễ gây confused vì chúng nó khá giống nhau. Trong nhiều ứng dụng thì 2 khái niệm này có thể thay thế cho nhau ( interchangeable ). Nó chỉ khác nhau đối với các trường hợp ứng dụng có nhiều business logic phức tạp. Nếu bạn nào quen với các Design Pattern rồi thì Repository tương ứng với Facade cho các DAO ở tầng DAL.

DAO thì nó gần hơn với mức lưu trữ ( storage ) và nó thực sự là data-centric đó là lý do tại sao có rất nhiều trường hợp 1 DAO sẽ được match 1-1 với 1 table trong database. DAO là nơi ẩn giấu các câu query và trả về các object state cho object client gọi nó. Repository thì đứng ơ tầng cao hơn, nó cũng xử lý data và che giấu các câu query nhưng data mà nó làm việc là domain object, có có thể gọi DAO để lấy dữ liệu từ tầng lưu trữ và dùng các dữ liệu đó để xử lý các domain object hoặc nó có thể extract data cần thiết từ domain object để lưu trữ vào storage. Cái khác nữa là Repository được implement theo pattern mà đồng chí Martin Flower định nghĩa ( tức là nó được cài đặt chương trình bơi khi máy bay bị rơi vì nó là phi công chứ không phải là đơn giản là một người bình thường ) . Cách hình dung dễ nhất về Repository là lấy một đối tượng tương tự là Collection để minh họa về nó, Repository giống như một collection các domain object. Với collection bạn có thể thơm hoặc bớt các phần tử của nó cũng như truy cập một phần tử nào đó qua index, còn với Repository bạn cũng có thể lấy ra một domain object, xóa nó đi lấy ra một domain object nào đó tùy theo điều kiện nào đó.

Các bạn cứ nhìn vào hình trên đây là sẽ hiểu về vai trò của Factory và Repository. Ở đây Gateway có thể nằm ở tầng Infrastructure và có thể là DAO hoặc cũng có thể là object truy cập vào một webservice ở bên ngoài.

Và để cho dễ nhớ về đám gạch đá ( bulding block ) để xây nhà theo kiến trúc DDD này thì chúng ta tóm tắt trong cái hình này cho dễ hình dung.

• Data Transfer Object: Tuy không phải là một phần của DDD nhưng cũng đưa vào đây vì nó vẫn đường được sử dụng trong mô hình nhiều lớp, đơn giản nó chỉ là các Object không có logic và chỉ được dùng để truyền dữ liệu qua các layer khác nhau trong ứng dụng mà thôi.

Viết nhiều chữ quá cũng không hiệu quả, nên phần kết của cái bài đi tìm câu trả lời cho câu hỏi What Design Driven Domain là cái gì mình sử dụng cái hình này, nhìn vào đó ta có thể thấy được thought process ( tư duy thiết kế tổng quan ) của DDD được triển khai như thế nào. Có một số khái niệm chưa được giải thích sẽ bổng sung thêm khi có thời gian.