Locked issues", how can we check the Issue's lock state without retrieving it from the database? If we have a business rule like "Users can not comment on the The answer is that we should implement the business rulesĪnd preserve the data consistency and integrity in the code. Why don't we just execute an SQL Insert command to database without querying any data? Getting the Issue with all details seems unnecessary and inefficient. That may seem strange to the developers used to work with EF Core & Relational Databases before. Save the Issue (with all sub-collections) to the database as a single database operation (update). Use methods on the Issue class to add a new comment, like Issue.AddComment(.). Get the Issue from database with including all the sub-collections (Comments and IssueLabels). For example, if you want to add a Comment to an Issue, you need to. Actually, we should try to implement business rules in the entities wherever possible.Īn aggregate is retrieved and saved as a single unit, with all the sub-collections and properties. That means, unlike the DTOs, Entities have methods to implement some business logic. The Aggregate Root Entities are also responsible for their sub-collection entities.Īn aggregate should maintain its self integrity and validity by implementing domain rules and constraints. Other aggregates are shown as simple since we will focus on the Issue Aggregate:Īs said before, an Aggregate is a cluster of objects (entities and value objects) bound together by an Aggregate Root object.Įntities are responsible to implement the business rules related to the properties of their own. Issue Aggregate consists of an Issue Aggregate Root that contains Comment and IssueLabel collections. The figure below shows some of the aggregates, aggregate roots, entities, value object and the relations between them:
The examples will use some concepts those are used by GitHub, like Issue, Repository, Label and User, you are already familiar with. You can follow these rules and apply in your solution while implementing the Domain Driven Design. We will introduce and explain some explicit rules with examples. This is the essential part of this series.
0 kommentar(er)
