3 ms·
The article and the comments are missing the most important thing. For DDD don't use SQL as your database. Postgress ( and eg. The excellent library martendb
by NicoJuicy 5y ago
The article and the comments are missing the most important thing.
For DDD don't use SQL as your database.
Postgress ( and eg. The excellent library martendb for dotnet) are perfect for this.
Dump ( or update) your object to the db and the ability to query some properties ( so you don't need an additional search service to query your data - https://martendb.io/documents/indexing/duplicated-fields.html https://martendb.io/documents/indexing/duplicated-fields.htm... )
Using SQL is going to give you a lot of unnecessary headaches when using DDD and trying basic crud.
- kebsup 5y agoCould you elaborate a little more on this? What kind of headaches do you have in mind? (No pun intended :D)
- rowls66 5y agoI disagree partially. I do agree that modeling your domain in programming language objects and then transforming those objects into data stored relational tables (OR Mapping) is not a great design. However, DDD can also be done where the relational database is the model of the domain, and the application is merely a set of functions that execute SQL and transform the results. So based on the application two approaches for persistence are possible: 1) Model the domain in the programming language, and store data as opaque blobs. 2) Model the domain in relational tables, and use the application logic to extract and transform the data.