Reputation: 205
Consider there is a domain for which a bounded context is to be created. However, nothing should be persisted in this domain. Just a purely task-based logic should be there and a hypothetical domain model won't be updated.
I see no way to apply entity pattern in such domain, only services and value objects come to my mind in this case. I'm now wondering, which one of the following statements is true:
Upvotes: 0
Views: 200
Reputation: 1582
From my experience, there is 2 misconceptions when it comes to DDD.
a) there is no "I do DDD" and "I don't do DDD". We're always somewhere in between, there is no black and white. It's like agile development. You can do some of it and get a benefit out of it. DDD is a way to build a domain model for your business (or technical) Domain.
b) the DDD Entity has nothing to do with the @Entity annotation. The DDD Entity is something identifiable (still not with an @Id Annotation!). And not identifiable by all its attributes, but by its existence for example in a repository.
I don't know what your problem space is. But let's say you're building a GUI. a GUI will not be persisted. But still you have elements in there that resemble entities (like a window maybe being a aggrregate root) and UI components definitely being entities in that domain. You will probably implement invariants that your aggregrates will ensure. You will probably have repositories that you can ask to return references to your UI components.
Just because you have no persisted state doesn't mean you can't apply DDD patterns.
Upvotes: 0