CODEWITHSUNDEEP
node.jsmodelcouchdbdomain-driven-designclean-architecture
Simon Bruneaud
Simon Bruneaud

Reputation: 2567

How to implement noSQL database abstraction?

I use CouchDB, a document oriented database that store data as JSON documents. I use Javascript on the backend, so I can directly store JS object. Currently I have a direct mapping between the models I store in CouchDB and my domain layer. I think it's not a good thing, because I'm totally dependant on this database.

Example

I have 2 entities users and projects. One user can have multiple projects, these models are represented as separate documents in the database:

user document 

{
  "_id": "1",
  "entity": "user"
}

projects documents
The relation are referenced by a property user_id.

{
  "_id": "2",
  "entity": "project",
  "user_id": "1",
  "name": "project1"
}

// other project document
{
  "_id": "3",
  "entity": "project",
  "user_id": "1",
  "name": "project2"
}

My question is:
Should I keep this convenient mapping between layers or should I create an abstraction layer that transform the models from the database into domain object ?

Example of a more convenient user domain object:

// _id property is replaced by id
// entity property is removed
// projects relations stand in a projects array
{
  id: "1",
  projects: [
   { id: "2", name: "project1"},
   { id: "2", name: "project1"}
  ]
}

Note: I would like to read the book "Domain Driven Design" from Eric Evans. Maybe it could help me to see how to manage such models abstractions.

Upvotes: 3

Views: 858

Answers (2)

rascio
rascio

Reputation: 9279

I think the question involve a lot DDD.
What are you struggling for are aggregates. Using a nosql db, a document should contain an aggregate.
Using different documents for entities inside the same aggregate will have the effect that persist an aggregate corresponds to multiple documents being stored, that can fails independently (causing a data corruption).
The DDD aggregate instead is the transactional boundary of your domain, the persist of an aggregate must be an atomic operation.

About the technical stuff, if depends remove them from the domain model is nice is clean etc...etc...
But just if leave them cause more problems then find a way to hide them from the domain. So it depends on the scale of the domain.

For more info this can be helpful: Why limit commands and events to one aggregate? CQRS + ES + DDD

Upvotes: 1

Golo Roden
Golo Roden

Reputation: 150892

IMHO this question is not that much related to DDD, but I am trying to answer it anyway ;-)

I would definitely translate the database objects into domain objects. The reason for this is pretty simple: If you ever change the underlying data store, your objects will change, and then you will have to update your domain code for a technical reason.

Apart from that, the database objects do contain way more than what is of interest to the domain. This is another reason to get rid off them: Model your domain objects so that they are clean and do what you expect them from.

Moreover, you want to be able to test your domain objects easily. If they contain all the database stuff, this makes it unnecessarily hard.

To cut a long story short: Don't use database objects in your domain layer.

Upvotes: 2

Related Questions