Let’s see what the blue book of DDD tells us about bounded contexts: In order to understand this statement better we need to consider another DDD concept: the bounded context. This explicitly shared stuff has special status, and shouldn’t be changed without consultation with the other team.”
#Bounded context example code
Of course this includes, along with this subset of the model, the subset of code or of the database design associated with that part of the model. “ Designate some subset of the domain model that the two teams agree to share. Let’s see what Eric Evans writes about a concept called the shared kernel: There’s something very similar for the domains of your business. You could put these within the project solution but then when you start your next project then you may need to copy and paste a lot of code. Putting these in a separate infrastructure layer helps if you want to employ the same logging, caching etc. Examples: logging, file operations, security, caching, helper classes for Date and String operations etc.
They are not specific to any single project or domain. The infrastructure layer is a place for all sorts of cross-cutting concerns and objects that can be used in any project.
#Bounded context example series
If you read the original DDD series starting here then you’ve come across something that we called the infrastructure layer. In this post we’ll look at a concept called the shared kernel and how the above mentioned concepts can be represented in code. The “boss” of the group is the aggregate root and it’s through the aggregate root that other aggregates communicate with other aggregates. Finally, aggregates are groups of objects that are treated as a unit for purposes of data persistence. As the IDs are immutable per se, value objects are consequently also immutable. We can say that a value object is also a type of entity but its ID is a composite of all its constituent properties. Value objects on the other hand are defined by their properties and are immutable. Its properties can change but its ID – whether a simple integer or a composite – should never be modified after the object has been created. We said that an entity is an object whose identity is defined by its ID key for the purpose of tracking its state through time. In the previous post we discussed 3 fundamental concepts in DDD: entities, value objects and aggregates with aggregate roots.
0 kommentar(er)
