Bảng tra cứu: Chúng có bị rò rỉ trong mô hình miền không?

Bạn đang xây dựng một hệ thống theo dõi các công ty. Những công ty có Liên hệ. Những người liên hệ đó thường là những chuyên gia chỉ trả lời một số loại câu hỏi nhất định, chẳng hạn như Thanh toán / Thanh toán, Bán hàng, Đặt hàng và Hỗ trợ Khách hàng.

Sử dụng Thiết kế hướng tên miền và Kiến trúc hành tây, tôi đã mô hình hóa điều này với các loại sau:

• Công ty
  • Có liên hệ
• Tiếp xúc
  • Có loại liên hệ
• ContactType (enum)
• CompanyRep repository (giao diện)
• EFCompanyRep repository (được xác định trong một tổ hợp bên ngoài, sử dụng EntityFramework, thực hiện CompanyRep repository )

Nhóm của chúng tôi có ý kiến ​​riêng về cách lập mô hình cơ sở dữ liệu cho ứng dụng này.

Bên A: DDDers Lean:

• Đó là công việc của Miền để xác định ContactTypes nào hợp lệ cho Liên hệ. Thêm một bảng vào cơ sở dữ liệu để xác thực rằng ContactTypes không xác định không được lưu là dấu hiệu của một miền bị rò rỉ. Nó lan truyền logic quá xa.
• Thêm một bảng tĩnh vào cơ sở dữ liệu và mã tương ứng là lãng phí. Trong ứng dụng này, cơ sở dữ liệu giải quyết một vấn đề: duy trì sự việc và trả lại cho tôi. Viết một bảng phụ và mã CRUD tương ứng là lãng phí.
• Thay đổi chiến lược cho sự kiên trì nên dễ dàng nhất có thể. Nó có nhiều khả năng thay đổi quy tắc kinh doanh đó. Nếu tôi quyết định rằng SQL Server tốn quá nhiều chi phí, tôi không muốn phải xây dựng lại tất cả các xác nhận hợp lệ mà tôi đã đặt trong lược đồ của mình.

Bên B: Những người theo chủ nghĩa truyền thống [có lẽ không phải là một tên công bằng. Các DBCentrists?]:

• Đó là một ý tưởng tồi để có dữ liệu trong cơ sở dữ liệu không có ý nghĩa nếu không đọc mã. Báo cáo và người tiêu dùng khác phải lặp lại danh sách các giá trị.
• Đó không phải là nhiều mã để tải từ điển loại db của bạn theo yêu cầu. Đừng lo lắng về nó.
• Nếu nguồn của mã này là mã chứ không phải dữ liệu, tôi sẽ phải triển khai các bit thay vì một tập lệnh SQL đơn giản khi nó thay đổi.

Không bên nào đúng hay sai, nhưng một trong số họ có thể hiệu quả hơn về lâu dài, tính thời gian phát triển cho sự phát triển ban đầu, lỗi, v.v ... Bên nào - hay có sự thỏa hiệp nào tốt hơn? Các đội khác viết kiểu mã này làm gì?

Bằng cách áp dụng DDD và kiến ​​trúc củ hành, bạn đã quyết định rằng cơ sở dữ liệu là thứ hai cho mô hình miền của bạn. Điều đó có nghĩa là, sẽ không có ai khác thực hiện các thao tác trên cơ sở dữ liệu ngoài mô hình. Nếu những người theo chủ nghĩa truyền thống không thích điều đó, họ nên phản đối việc sử dụng DDD ngay từ đầu.

Điều đầu tiên là rõ ràng: bạn cần "bảng tra cứu" trong mô hình. Mô hình của bạn cần phân biệt giữa các loại liên hệ khác nhau. Điều đó có nghĩa là, nó giữ danh sách đánh máy mạnh mẽ của tất cả các loại. Cũng cần phải ánh xạ từ các loại mạnh đến các giá trị được tuần tự hóa sang cơ sở dữ liệu. Ánh xạ này có thể nằm trong mô-đun cơ sở dữ liệu. Nhưng danh sách tất cả các loại có thể vẫn sẽ có trong mô hình. Và nếu mô hình là nguồn duy nhất của sự thật, thì nó không thể ở trong cơ sở dữ liệu. Hoặc ít nhất, khi danh sách thay đổi trong mô hình, nó cần thay đổi trong cơ sở dữ liệu. Và không có buts!

Các đối tượng miền dừng là các đối tượng miền khi chúng vượt qua một ranh giới quá trình . Ngay cả khi cơ sở dữ liệu chỉ là một cửa hàng bền bỉ, đến một lúc nào đó trong tương lai, nhu cầu của doanh nghiệp sẽ gây ra thay đổi cho mô hình domaim không phù hợp với lịch sử vẫn tồn tại và dù sao bạn cũng sẽ cần một lớp chống tham nhũng ....

Điều đó nói rằng, tôi nghĩ rằng DBCentrists của bạn đang thiếu thuyền. Các nhà lập mô hình miền đang nói rằng họ cần một cửa hàng kiên trì. "Báo cáo và người tiêu dùng khác" cần một cái gì đó mà họ có thể truy vấn - thứ gì đó có chỉ số khá, như đã được ghi nhận trong các bình luận.

Ai đã đưa ra ràng buộc rằng tất cả những mối quan tâm khác nhau này cần được hỗ trợ bởi một cơ sở dữ liệu? Điều gì xảy ra nếu bạn đẩy lùi điều đó.

Từ khóa tìm kiếm: CQRS.

Tôi đã tìm thấy tốt nhất để lưu trữ enums như đại diện chuỗi của họ trong cơ sở dữ liệu và không bao gồm bảng tra cứu.

Rõ ràng nhược điểm của việc này là nó sử dụng nhiều dung lượng đĩa hơn và không được chuẩn hóa.

Mặt tích cực là trường vẫn giữ nguyên ý nghĩa của nó trong db, bạn không kết thúc với các số ma thuật ăn mòn với giá trị int của enum chẳng hạn và bạn không phải quản lý phiên bản bảng tra cứu khi enum thay đổi.

Không chắc chắn tôi sẽ mô tả điều này như là một sự khác biệt DDD so với Trad. Theo quan điểm của tôi, nhiều hơn một cơ sở dữ liệu tập trung so với mã là tốt nhất

• Miễn là bạn đang sử dụng cơ sở dữ liệu quan hệ, bạn nên giữ các bảng được chuẩn hóa ở mức hợp lý. Bình thường hóa giúp ngăn chặn chèn và cập nhật bất thường.
• Mối quan hệ một ứng dụng <-> một cơ sở dữ liệu không còn phổ biến, nhiều ứng dụng có thể sử dụng nhiều cơ sở dữ liệu và một cơ sở dữ liệu có thể được sử dụng bởi nhiều ứng dụng, do đó, việc cơ sở dữ liệu thực thi tính toàn vẹn tham chiếu càng nhiều càng tốt.
• RDBMS là bạn của bạn.
• Bạn có thể đi với một bộ lưu trữ khóa-giá trị thay thế và làm mọi thứ trong mã.