Khi chúng ta tạo ra một ứng dụng phần mềm, một phần lớn các thành phần của ứng dụng không liên quan trực tiếp đến nghiệp vụ nhưng chúng là một phần của hạ tầng của phần mềm hoặc phục vụ chính bản thân ứng dụng. Một ứng dụng điển hình bao giờ cũng có cơ sở dữ liệu, các tập tin, văn bản, giao diện người dùng

Trong một ứng dụng thông thường thì chúng ta sẽ thường cấu trúc phần cơ sở dữ liệu, giao diện người dùng, và các chức năng hỗ trợ khác được đặt cùng trong phần logic, nghiệp vụ của ứng dụng. Thêm vào đó phần logic nghiệp vụ thì thường lại được đặt lẫn lộn trong phần tương tác với người dùng hoặc các kịch bản tương tác với database. Mô hình phát triển hướng đối tượng (OOP) trở nên phi thực tế, phần kiểm thử tự động khó khăn ( test code). Do đó khi hệ thống càng lớn hơn thì cấu trúc source code sẽ ngày càng trở nên phức tạp và dẫn tới khó kiểm soát được. Chương trình cần được viết một cách đơn giản và rõ ràng không thì sẽ không kiểm soát được

Do đó hãy phân chia chương trình thành các lớp, phát triển và thiết kế các lớp để chúng trở nên gắn kết và chỉ phụ thuộc vào lớp bên dưới. Tập trung phân chia thành các lớp chú trọng vào nghiệp vụ, tách biệt với lớp giao diện người dùng (UI), ứng dụng (Application) và infrastructure. Đây cũng chính là kiến trúc phân lớp trong DDD và nó được chia thành 4 lớp:

User Interface (UI)

Hiểu một cách đơn giản, lớp này dùng để hiển thị thông tin cho người sử dụng và thu nhận dữ liệu mới. Nó có thể được thực hiện bởi ứng dụng Web, Desktop hoặc bằng bất kỳ công nghệ trình bày nào. Ví dụ nó có thể là một ứng dụng thoại mà có thể tương tác với người dùng qua điện thoại. Nguyên tắc cơ bản của nó là bất kỳ một thay đổi căn bản nào của UI thì nó nên ảnh hưởng rất nhỏ đến phần còn lại của hệ thống

Application

Có nhiệm vụ giám sát  điều phối các hoạt động ứng dụng mà được thực thi trên Domain.

Không chứa logic và nghiệp vụ, không lưu giữ trạng thái của nghiệp vụ. 

Chuyển toàn bộ các hoạt động mà cần tương tác với domain đến lớp Domain và có thể phối hợp các hoạt động cần tương tác với nhiều Domain khác nhau

Domain

Lớp này chính là trái tim nghiệp vụ phần mềm theo Eric Van, các nghiệp vụ và logic được đặt trong lớp này. Các trạng thái và hoạt động của Entity (Class) mà dùng để diễn tả các nghiệp vụ thì được đặt ở đây. Nó là các thông tin trao đổi với các hệ thống khác nhau, hoặc diễn tả các đối tượng mà có thể dùng để lưu vào database, hoặc dùng để chuyển tiếp đến lớp infrastructure như repository. Eric Van đã trình bày các pattern mà ông dùng trong lớp này như là: Entity, Value Object, Service, Repository và Factory. Mình sẽ trình bày rõ hơn cho các bạn ở bài tiếp theo

Infrastructure

Lớp này đóng vai trò như một thư viện hỗ trợ cho tất cả các lớp hiện tại. Nó cung cấp các thông tin liên lạc giữa các lớp, cài đặt persistent nghiệp vụ cho các đối tượng nghiệp vụ,  thường xuyên nhất dùng truy cập database

Điều quan trọng nhất là DDD đã giúp chúng ta phân chia ứng dụng ra thành các lớp riêng biệt và thiết lập nên các quy tắc để chúng tương tác với nhau, nếu nhìn vào hình vẽ ở trên bạn sẽ thấy rằng các lớp trên thì có thể truy cập xuống lớp bên dưới nhưng lớp dưới không thể truy cập vào lớp trên.

Nếu cấu trúc code không được phân chia rõ ràng như thế nó sẽ gây nên sự chồng chéo, phức tạp gây khó khăn trong việc quản lý chất lượng code.  Một thay đổi nhỏ cũng có thể ảnh hưởng đến cấu trúc hiện tại, gây nên bug hoặc khó kiểm soát được ảnh hưởng của nó đến logic hiện tại.

Lớp Domain chỉ nên tập trung vào phần logic và nghiệp vụ không nên ảnh hưởng đến phần tương tác với database trong phần Infrastrucutre. Giao diện của người dùng không nên kết nối quá chặt chẽ đến các nghiệp vụ và logic của Domain hoặc làm những nhiệm vụ liên quan đến phần Infrastucture. Một application có vai trò quản lý các logic nghiệp vụ của lớp domain nhưng cũng có thể giám sát hoặc điều phối toàn bộ các hoạt động của ứng dụng