CODEWITHSUNDEEP
domain-driven-design
damike
damike

Reputation: 345

Validation / Business rules with related objects

Assume I have an class with nested properties: root.propA.propB.propC, where each prop is represented by an class: propA by classA, propB by classB, propC by classC and root = aggregate.

Assume that several objects correlate to each other: root1 --> (root2, root3), root2 --> root4, root4 --> root1.

In DDD the “validation logic” / “business rules” should be in each class. I want to full context in each class for executing rules. For example: propC is represented by classC – there I want a context with:

How can that be solved?

  1. Inject a context in CTR of every class and set the properties of related root objects afterwards?
  2. Every class has a List of related root objects?

I couldnt find examples with DDD and related objects

Upvotes: 0

Views: 276

Answers (1)

ArwynFr
ArwynFr

Reputation: 1722

root1, root2, root3, root4 (since they are related): For example, I want to ensure, that only 1 propC has a certain value

In DDD, an aggregate is a collection of related objects that are validated atomically by the business layer. The validation logic code is split across all classes (root, classA, classB, classC) for easier implementation, but the command ultimately makes updates to the aggregate's state and then validates that this target state does not violate any business rule. Once validated, it delegates the state persistence to the infrastructure layer, that will update storage in a transaction.

The root aggregate instance is a boundary that cannot be crossed inside the transaction or for business rule validation. If you need to enforce any business rules across multiple aggregate instances, then you may:

  • make a wider aggregate that contains all related root objects
  • use a two-phase commit distributed transaction
  • use a saga pattern

I want the parent of propC: For example, I want to check that the parent has a certain value (should be possible with entity framework as navigation property?)

The aggregate is atomic, so you always manipulate the root object and all dependent properties. The parent of root.propA.propB.propC is root.propA.propB so you can access that. You may add a navigation property to ClassC so you can access propB from propC if you want.

A word of warning though: Entity Framework is an ORM, it is used for persistence in the infrastructure layer, and is a unit of work pattern implementation. It does not apply to domain modeling, because persisting your domain state to a RDBMS with EF rather that storing the state in an event sourcing repository, an xml file accessed through FTPS, or a nosql document database, is an infrastructure implementation detail.

Matching your domain model and your persistence model works only for very simple applications. You will quickly need to restrain the complexity of your business model to smaller polysemic designs instead of reading your whole persistence store.

It's up to you to choose where you draw the limit between merging overlapping aggregates data into a shared storage, and splitting them into different database-per-service. This limit is called a bounded context.

Upvotes: 1

Related Questions