0

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
HectorBarbossa
  • 185
  • 1
  • 3
  • 9
  • 2
    Is that a virtual question or do you have a real life problem domain to illustrate it? – guillaume31 Oct 27 '17 at 11:45
  • It is a good question but I believe that the answer depends on the business context we are discussing here. I agree with @guillaume31, can you expand on the business problem please? – Alessandro Santini Oct 28 '17 at 07:52

1 Answers1

0

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.

EasterBunnyBugSmasher
  • 1,507
  • 2
  • 15
  • 34