HectorBarbossa
HectorBarbossa

Reputation: 205

How to apply DDD to context without explicit domain model

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:

  1. This is the kind of subdomain that DDD shouldn't be applied to
  2. The problem is with the strategic design and such subdomain should never be extracted as a separate bounded context
  3. It is alright to create a domain model with just services and value objects

Upvotes: 0

Views: 200

Answers (1)

EasterBunnyBugSmasher
EasterBunnyBugSmasher

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

Related Questions