5

I have a NoSQL DB with parts of my data denormalized and duplicated. For concreteness, let's say I have:

  1. A document set called "people" containing full specifications of people.
  2. A document set called "votes" containing outcomes of voting rounds in a certain organization. Each vote document has an embedded list of people who voted for and against. The elements of such a list contain a subset of data compared to what's stored in a "people" document.

Is it in accordance or against DDD principles to have two separate model classes in my app, each representing a person - one with the full spec (queried from "people"), one with the subset of data (queried from "votes")? E.g. Person and VotingPerson.

It seems to me such a solution falls within the scope of the "bounded context" idea, therefore making it fine, but I want to make sure.

Thanks!

Improve this question
3
  • It's perfectly in accordance with the CQRS patterns read- and write model. Where your read model is a projection specialized for the given report or output. Commented Oct 9, 2017 at 12:18
  • Since noSQL databases do not benefit technically from normalisation it sounds good to me... Commented Oct 9, 2017 at 12:57
  • Well ideally, you'd only retain information related to the actual voting in the list itself with a reference to the key to the people set where more information is available, but understandably it may not be convenient to perform two queries for one otherwise copied field. Just don't do it when consistency is important. Commented Oct 9, 2017 at 12:59

2 Answers 2

Reset to default
3

From DDD point view, people usually pay less attention on the particular persistent store, instead they focus on polishing the domain models. After all the persistence is just an infrastructure or implementation detail concern.

It's also totally fine to have two domain models to represent the same physical thing. In the sample of Vaughn Vernon's IDDD book, he uses BacklogItem and ProductBacklogItem in projectPM bounded context. In this case, he modeled backlog item in two different ways when they belong (or not) to the product.

It's also very common to have different representations cross boundaries. Again in IDDD, Vaughn Vernon uses Ports & Adapters pattern to translate user and role combination in Identity and Access boundary to a bunch of collaborators.

Improve this answer
1

FOr that, you would need to look at your requirments.

Technically, since NoSQL stores may requires you to duplicate some data it's fine. But I don't think it's related to Domain Driver-Design, DDD is way higher than such issues.

Now what is the specific requirments about the functionnality of your votes ?

  1. Stores somewhere who votes so they can't vote twice ?
  2. Be able to consult who voted what ?
  3. Others requirments ? What data would be needed from People ? either by systems interacting with each others or in the User Interface.

In the case on one, keeping a non-modifiable unique identifier of your "People" is enough. On the second :

  • You can perform some sort of JOIN between the unique identifier and the "People" stores, however this may be quite inconvenient for your NoSQL store, some support that, some don't and it might occurs quite a penalty to do it manually.
  • You may need to add for instance first name and last name, and in the UI you will have a link with the text being "First Name Last Name". The link could open a new window to the classic People information retrived from the "People" store. However keep in mind that if first name and last name data are modifiable, you will need to update it there too whe it'll happens.

Eventually your requirments would specify something like :

There is one detailed view of People, all others page that shows people should only show their last name and first name and a link redirecting to the detailed view.

Improve this answer
2
  • Thanks for this, though I can't quite see how it addresses my question.. The primary issue here is whether I could break some DDD rule (and the good reasons behind it) by introducing another, thinner representation of the same entity, only because I don't want to make another query to the "people" document set (JOINs are not an option - it's NoSQL). Commented Oct 10, 2017 at 8:13
  • My point about DDD is that is to low level to affect DDD rules, the rest is about the possibles implementation depending of your exact requirments. Note : some NoSQL do perform JOIN, maybe not yours, and even if he does it might be very inneficient depending how it is used. Commented Oct 10, 2017 at 17:11

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.