Menu
I am implementing DDD with Entity Framework Code First. My Domain Model is persisted as it is without any mapping layer.
I am following approach suggested during Tech-Ed by Julie Lerman. Each bounded context maps to different schema within same database.
If same entity say, Customer appears across different bounded contexts how do we maintain consistency of data for Customer entity?
997
Bounded Context and Ubiquitous Language. To solve the addressed issue, DDD provides the concept of Bounded Context. A Bounded Context is a logical boundary of a domain where particular terms and rules apply consistently. Inside this boundary, all terms, definitions, and concepts form the Ubiquitous Language.
A domain entity in DDD must implement the domain logic or behavior related to the entity data (the object accessed in memory). For example, as part of an order entity class you must have business logic and operations implemented as methods for tasks such as adding an order item, data validation, and total calculation.
Each Microservice uses its own database to persist data of domain model of a Bounded Context. A single Bounded Context can include many aggregate roots, or we can organise a single aggregate root into a single Bounded Context.
Aggregates represent business entities, and thus are smaller in scope than Bounded Contexts, which represent entire domains. Aggregates encapsulate data, whereas Bounded Contexts encapsulate services, team members, and their shared language(s)
Only a single bounded context will be the system of record for your entity. If you cannot get away with simply an Id in the other BCs then you can include a subset of the entity (usually not all the properties) as a value object.
Any changes to the entity in the SOR should be published as one or more events in a messaging system that the downstream BCs subscribe to in order to keep their data eventually consistent.
70
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
