I am trying to understand DDD. Infact it looks I have some missing points on OOP. Let's think that we have a domain model called Product. Based on OOP, data and behaviour must be hold together. Example maybe wrong but data and behavior are together below.
public class Product
{
public Guid Id { get; set; }
public double TaxRate { get; set; }
public double Price { get; set; }
public double GetFinalPrice()
{
return Price * TaxRate;
}
}
Let's think that we need to fetch all products in a category, in this case should I add a method in Product class to return all products in a category? It doesn't look good to me, because a GetProducts behaviour cannot be in Product object.
In this case should I create a CategoryProductFetcher object and add a method Fetch for behaviour?It also sounds wrong because I will have a class for all list methods.
Could you help me about the concept or any documents that explain this? I read lots of article but all are to basic and not explaining more.
Thanks in advance
You may need to look up some additional concepts from DDD:
Aggregate
Application Layer
Repositories
CQRS
An aggregate can only be responsible for behaviour within the aggregate. Specifically, a 'Product' aggregate (singular) can only be responsible for what goes on within that instance of a Product. It should not be responsible for retrieving other products for you.
Repositories are the intermediaries between your application layer and data storage. They provide means of retrieving aggregates ready for a command to be executed on them. They also provide means of adding new aggregates to your data storage.
The application layer will retrieve aggregates from repositories and then ask the aggregate to perform functionality WITHIN the boundary of that single aggregate instance.
CQRS is the idea that your classes in a domain model are responsible for implementing the logic within a command use case. A command use case is one that changes the state of the existing data.
CQRS then suggests that your queries should take a different path (not thru your domain objects). For example, your query module may query the database directly and project that data into DTOs for return to the client.
Asking a repository to retrieve a specific aggregate should be done performing a write operation on the same. That means, repositories should be optimized for write operations when retrieving and performing operations on aggregates than need to execute business logic and adhere to business invariants. Thus data shall be only changed through single transactions on aggregates and those aggregates shall be persisted through their respective repository.
Queries on the other hand should be optimized for read operations and can and should bypass repositories as well as aggregates and retrieve data needed for the respective use case that does not involve changing data. This data can also be combined from different aggregates.
For instance, changing a product should happen through the product aggregate's provided operations (methods) and then again be persisted through the aggregate. If, for instance, you just need to display a list of product information of a respective category go through queries that are optimized to retrieve just the data you need for that use case. As repositories are always loaded completely to make sure all business rules can performed correctly when changing the same repositories are not suited for retrieving a large amount of aggregates and the read optimized queries should be used instead.
Reading Material:
The Blue Book
The Red Book
Related
I am developing a website for a beauty salon. There is an admin part of the website, where the esthetician can add a new care. A care is linked to a care category (all cares related to hands, feets, massages, ...). To solve this I wrote this code into the CareRepository in the .NET API :
public async Task<Care?> AddAsync(Care care)
{
// var dbCareCategory = await this._careCategoryRepository.GetByNameAsync(care.CareCategoryName);
if (string.IsNullOrEmpty(care.CareCategoryName) || string.IsNullOrWhiteSpace(care.CareCategoryName))
return null;
var dbCareCategory = await this._instituteDbContext.CareCategories
.Where(careCategory => Equals(careCategory.Name, care.CareCategoryName))
.Include(careCategory => careCategory.Cares)
.FirstOrDefaultAsync();
if (dbCareCategory == null || dbCareCategory.Cares.Contains(care))
return null; // TODO : improve handling
dbCareCategory.Cares.Add(care);
await this._instituteDbContext.SaveChangesAsync();
return care;
}
My problem here is that I am a bit struggling with the best practice to have, because in order to add a care to a category, I have to get the category first. At the first place, I called the CareCategoryRepository to get the care (commented line). But then, EF was not tracking the change, so when I tried to add the care, it was not registered in the database. But once I call the category from the CareRepository, EF tracks the change and saves the Care in the database.
I assume this is because when calling from another repository, it is a different db context that tracks the changes of my entity. Please correct me if my assumption is wrong.
So, I am wondering, what is the best practice in this case ?
Keep doing what I am doing here, there is no issue to be calling the category entities from the care repository.
Change my solution and put the AddCare method into the CareCategoryRepository, because it makes more sense to call the categories entities from the CareCategoryRepository.
Something else ?
This solution works fine, however I feel like it may not be the best way to solve this.
The issue with passing entities around in web applications is that when your controller passes an entity to serve as a model for the view, this goes to the view engine on the server to consume and build the HTML for the view, but what comes back to the controller when a form is posted or an AJAX call is made is not an entity. It is a block of data cast to look like an entity.
A better way to think of it is that your Add method accepts a view model called AddCareViewModel which contains all of the fields and FKs needed to create a new Care entity. Think about the process you would use in that case. You would want to validate that the required fields are present, and that the FKs (CareCategory etc.) are valid, then construct a Care entity with that data. Accepting an "entity" from the client side of the request is trusting the client browser to construct a valid entity without any way to validate it. Never trust anything from the client.
Personally I use the repository pattern to serve as a factory for entities, though this could also be a separate class. I use the Repository since it already has access to everything needed. Factory methods offer a standard way of composing a new entity and ensuring that all required data is provided:
var care = _careRepository.Create(addCareViewModel.CareCategoryId,
/* all other required fields */);
care.OptionalField = addCareViewModel.OptionalField; // copy across optional data.
_context.SaveChanges(); // or ideally committed via a Unit of Work wrapper.
So for instance if a new Care requires a name, a category Id, and several other required fields, the Create method accepts those required fields and validates that they are provided. When it comes to FKs, the repository can load a reference to set the navigation property. (Also ensuring that a valid ID was given at the same time)
I don't recommend using a Generic Repository pattern with EF. (I.e. Repository()) Arguably the only reason to use a Repository pattern at all with EF would be to facilitate unit testing. Your code will be a lot simpler to understand/maintain, and almost certainly perform faster without a Repository. The DbContext already serves all of those needs and as a Unit of Work. When using a Repository to serve as a point of abstraction for enabling unit testing, instead of Generic, or per-entity repositories, I would suggest defining repositories like you would a Controller, with effectively a one-to-one responsibility.
If I have a CareController then I'd have a CareRepository that served all needs of the CareController. (Not just Care entities) The alternative is that the CareController would need several repository references, and each Repository would now potentially serve several controllers meaning it would have several reasons to change. Scoping a repository to serve the needs of a controller gives it only one reason to change. Sure, several repositories would potentially have methods to retrieve the same entity, but only one repository/controller should be typically responsible for creating/updating entities. (Plus repositories can always reference one another if you really want to see something as simple as Read methods implemented only once)
If using multiple repositories, the next thing to check is to ensure that the DbContext instance used is always scoped to the Web Request, and not something like Transient.
For instance if I have a CareRepository with a Create method that calls a CareCategoryRepository to get a CareCategory reference:
public Care Create(string name, int careCategoryId)
{
if (string.IsNullOrEmpty(name)) throw new ArgumentNullException(nameOf(name));
var care = new Care { Name = name };
var careCategory = _careCategoryRepository.GetById(careCategoryId);
care.CareCategory = careCategory;
_context.Cares.Add(care);
}
We would want to ensure that the DbContext reference (_context) in all of our repositories, and our controller/UnitOfWork if the controller is going to signal the commit with SaveChanges, are pointing at the exact same single reference. This applies whether repositories call each other or a controller fetches data from multiple repositories.
We have a solution based in DDD and we want to get all the information of certain entity, including all its aggregates. For example, something like this:
Which could be the best approach to get all the information of the Order aggregate including the Buyer aggregate data?
I was thinking that using the API Gateway to get these entities and provide a DTO as a response could work, but I don't know if it would be the best practice in this case.
So, our goal is call a service (here it's the problem) that could provide the information of the main entity (e.g. Order) and all information of its related entities (e.g. Buyer), but the Order model is related to it through a property named BuyerId.
You already know some component needs to be responsible for data aggregation. It usually boils down to deciding whether the aggregation will occur downstream (e.g. UI) or upstream (e.g. server).
If the APIs are already in place to gather the Buyer's data and the Order's data and the downstream client has the necessary correlation IDs on hand then it becomes possible for the downstream client to deal with the complexity of aggregating data. Whether this is acceptable or not is another story.
If you want to solve data aggregation issues upstream then you will most likely have two main strategies to choose from:
Aggregate in the application
public OrderDetailsDto orderDetails(OrderId orderId) {
//Repositories could be switched to remote API calls
Order order = orderRepository.findById(orderId);
Buyer buyer = buyerRepository.findById(order.buyerId);
return dtoAssembler.orderDetailsFrom(order, buyer);
}
Aggregate in the database
public OrderDetailsDto orderDetails(OrderId orderId) {
ResultSet resultSet = orderDetailsFromDb(orderId);
return dtoAssembler.orderDetailsFrom(resultSet);
}
Probably, we need to use a DTO
As you can see, both implementations could return the same DTO. Using explicit DTOs is a very useful and popular approach to deal with contract & serialization issues. How data is mapped into such DTOs is completely up to you and there are a multitude of implementation strategies.
I'm trying to use domain driven design while creating a website that is publicly accessible. One problem I'm having is trying to figure out what the aggregate roots should be for my model. I have a pretty good idea of what objects are entity objects and what objects are value objects.
My site, like most public sites, does not allow every user to see every piece of information stored in the site. Instead, they can only see the information they own. In the case of my site users will create "Projects" which they can also share with other users. Yet users can still only see information in projects they created or were invited to join. All the other objects in my model exists within a project and if a project is delete all the objects it contains should also be deleted.
So does this mean that I should have one main "Project" aggregate root type, and one "ProjectRepository" repository? It just seems inefficient to me to load an entire project each time any page on my site is requested. In reality this is not so much of an issue because I'm using NHibernate which will lazy load only the items in the project that are requested. Yet it seems like bad design to have the efficiency of the site depend so heavily on using an ORM with lazy loading.
Here's an update that will hopefully make my question more clear.
First I'm trying to understand if my Project type should be an aggregate root of my model. A Project can exist by itself, whereas the Reports must exist within a Project. If a Project is deleted the corresponding Reports should be deleted. Does this mean Project could be or should be an aggregate root? This I'm not very clear on.
If Project is an aggregate root then Report should not be correct? As I understand it roots should not be nested in DDD. In addition, only aggregate roots are allowed to be retrieved from repositories. So if Report is not aggregate root then I should not have a ReportsRepository, and instead should only be accessing a Report through a Project retrieved from a ProjectsRepository. So even if a page only requires data from a single report it would need to load the entire Project from the ProjectRepository to get at the report.
In addition, if Project is an aggregate root which contains Reports then removing a Project from a ProjectRepository could also be setup to remove the Reports it contains. Yet if both Project and Report are aggregate roots then wouldn't allowing the ProjectRepository to remove Reports when an Project is removed break the boundaries between aggregates? Aren't aggregate roots and their corresponding repositories suppose to act independent from one another?
I think you are confusing concerns. Security (who can view what) is not a domain concern. Don't let it pollute your domain. If a user cannot view a report within a project, enforce that at someplace other than the domain model.
In addition, I think you might benefit from decoupling your ViewModel (which is used for reading) from your domain model (which is mostly used for writing). They both share a data model (because they're reading from the same DB schema), but they really have different purposes.
In practice (in .NET), decoupling your ViewModel would have most or all of the following characteristics:
Your ASP.NET MVC views are bound to a single class which represents all the data on the screen. For example, not just the currently selected value in a <select> element, but a property representing all the possible <option> values in the <select> element.
These are in the MyProject.ViewModel namespace:
public class ProjectLead // Note that this class is specifically designed for display. This is not the domain object.
{
public Guid Id;
public string Name;
}
public class ProjectViewModel
{
public Guid ProjectLeadId;
public IEnumerable<ProjectLead> ProjectLeads;
}
Your Edit() controller action would call something like:
new ProjectViewModelRepository.Load(id);
ProjectViewModelRepository will map your data model (nHibernate classes or ADO.NET data rows or whatever) to the ProjectViewModel instance.
Then, the controller action called by submitting the form in the UI looks like this:
public ActionResult Edit(ProjectViewModel viewModel)
{
var repo = new ProjectRepository();
var project = repo.Load(viewModel.Id);
// Map the properties of the viewmodel to properties/methods of the Project domain class
repo.Save(project);
}
The big idea here is the Single Responsibility Principle. ProjectViewModel represents how a project is displayed on the screen. The Project domain class represents the business logic and whatnot associated with a project, independent of how that data is displayed on the screen.
Separating these things really solved a lot of problems due to the fact that I was using my domain classes for multiple purposes: persistence, domain logic, and display. But... if this all sounds like complete overkill I'd verify whether your domain is complicated enough to really warrant DDD.
We are implementing a SOA web application using EF, WCF and jQuery.
Here is our architecture in a brief view:
------------- ---
| UI | | |
------------- | |
| Services | | D |
------------- | T |
| Businsess | | O |
------------- | |
| Dal | | |
------------- ---
We know that we should have DTO classes to pass data between the layers specially between the Services and the UI but We have some conceptual issues about the way of using DTOs (to send to the UI or receive from UI).
For Data-Driven project we can use POCO to generate the DTO objects automaticly. But in big applications it's not that simple.
We know two solutions to solve our issue:
First solution (using POCO besides the new manually created DTOs)
For example suppose that we have an entity with many fields. And there is a lookup combobox that shows the entity records. We need just an entity key as the combobox value field and another field (for example Title) as the combobox text field. So we create a method named "GetAllItemsTitle" to retrieve all entities. Now we should just return the structure which we want (A key and a value in this example). So we have to create a new class to store that structure (A key and a value) in it.
This will be the new DTO class:
[DataContract]
public class SampleManuallyDto
{
[DataMember]
public long Id { get; set; }
[DataMember]
public string Title { get; set; }
}
And the method signature is like this:
public List<SampleManuallyDto> GetAllItemsTitle()
Second solution (using Nullable or Emptyable DTOs)
We can bypass the POCO and create DTOs manually. Then we may define all properties of the DTO as nullable or something like that which could be recognized as Empty (I called it Emptyable). It allows us to use a DTO for several purposes. Ofcourse we need to follow the Adapter pattern. For example create two method for those Emptyable DTOs named "FromEntity" and "ToEntity" that converts our manually created DTOs to EntityObjects (of entity framework).
Now we can bypass the creation of a new DTO classes in the example of the "first solution" (GetAllItemsTitle).
The method signature will be like this:
public List<SampleDTO> GetAllItemsTitle()
But in the method body we just fill the "Id" and "Title" properties of the SampleDTO. As I said all properties of the SampleDTO can be empty so we just fill those we want and leave the others empty.
Conclusion
Generally, the first solution (using POCO besides the new manually created DTOs) is Strongy-Typed. It's simply possible to find out each method return data type by just looking at the method signature (there is no extra properties). But we are worry about managing manually created DTOs. They will grow up soon.
But the second solution is a more dynamic way and the only way to recognize what will be returned from the "GetAllItemsTitle" is looking at the method body or its documentation. So we are worry about "Runtime Errors". Developers may suppose that a property should not be empty while it is empty.
More over, the expressed example we faced to such issue when "Puting" data from UI to Services. For example for Update and Insert and other such action. Even about the "Search Criterias" we have the same choises.
Sorry for the long question.
Please help us with your kindly advices.
Forget all about the data layer. Create DTO:s that works for each specific web service call.
It's not important how the DTO is built or how it's used. The only thing that matters is how they are designed to minimize the amount of webservice calls for each operation.
For instance: Let's say that you have a use case where you need to traverse all users to to modify their addresses. A bad design would be if you first need to fetch all users and then make a webservice call for each user to fetch it's address. A proper design would be to return a list of UserWithAddress DTO:s in a single call.
then how we manage the huge amount of DTOs of a large project? you mean we should have a DTO for every single combination of UserInfo, such as UserWithAddress, UserWithAddressAndAge, UserWithAge,UserWithPhoneNumber,UserWithBlahBlahBlah? This would be a mess in large domains and hard to manage and maintain. I really prefer the Nullable DTOs.
You should have a single Dto for each object mapped from the real world. this is the business duty to specify how it should be used. once you create a Dto, then use it according to you business. Calling GetUserAddress service, and don't expect UserAge or any other thing. there is a single DTO for Users as we map the user to our Object Oriented User in our design.
and one more thing! if we create a Dto for our each single purpose and combination of data services receives, as a developer who is joined to support team recently, how can i find a desired Dto for my new method? i should search all Dtos and be careful of my right choices (what happens if i be a lazy and careless developer?) maybe i should read a doc book like "THE DTOS OF THE PROJECT!" to become familiar with available DTOs.
DTOs should map to request or to capability based on need. You may aggregate various underlying data entities and return a composited or facade-like DTO, or you may return an anemic DTO that represents only a fraction of a single data entity. You want to balance payload, granularity and other SOA concerns when making this decision.
http://www.soapatterns.org/entity_abstraction.php
I'm building a web-service to retrieve a list of composite objects. Should a complex sub-property of each object in the list be populated at once or is it OK to have client request that info as needed.
Example:
class InvoiceLine
{
string ServiceDescription;
decimal ChargeTotal;
}
class Invoice
{
string InvoiceNumber;
string CustomerNumber;
List<InvoiceLine> InvoiceLines;
}
//Returns all invoices send to this customer
public List<Invoice> GetInvoices(string customerNumber);
Is it bad design to have another method in WebService as:
public List<InvoiceLine> GetInvoiceLines(string invoiceNumber)
and require client to first get a list of all saved invoices (with empty list of InvoiceLines in them, and expect them to call:
invoices[0].InvoiceLines = webService.GetInvoiceLines(customerNumber);
to simulate a "lazy-load".
This seems like a good way to save on volume but at the expense of more calls to get data when needed. Is this worth it or is that an anti-pattern of some sort?
It just doesn't seem right to return a half-populated object...
Thanks in advance for any pointers / links.
Service interface granularity is always an important decision when designing your services. Since web service calls are usually network calls or, at the very least, out of process calls they are relatively expensive. If your service interface is too fine grained (or "chatty") then this can affect performance. Of course, you need to consider your application and your requirements when determining the correct level of granularity. Software components: Coarse-grained versus fine-grained although a little dry has some good information.
It just doesn't seem right to return a
half-populated object...
I agree.
In your case let's assume that InvoiceLines is expensive to retrieve and not required most of the time. If that is the case you can encapsulate the invoice summary or header and return that information. However, if the consumer needs the full invoice then offer them the ability to do that.
class InvoiceLine
{
string ServiceDescription;
decimal ChargeTotal;
}
class Invoice
{
InvoiceSummary InvoiceSummary;
List<InvoiceLine> InvoiceLines;
}
class InvoiceSummary
{
string InvoiceNumber;
string CustomerNumber;
}
public InvoiceSummary GetInvoiceSummary(string customerNumber);
public Invoice GetInvoice(string customerNumber);
In general, I prefer to avoid imposing a sequence of calls on the consumer of the service. i.e. First you have to get the Invoice and then you have to get the Details. This can lead to performance issues and also tighter coupling between the applications.
Web services should not be "chatty": you're communicating over a network, and any request/response exchange costs time. You don't want to require the client to ask ten times when he could ask once.
Let the client request all of the data at once.
If that turns out to be a performance problem, then allow the client to specify how much of the data they want, but it should still all be returned in a single call.
I don't think it's bad design, I think it's a trade-off that you have to consider. Which is more important: Returning a complete object graph, or the potential transmission savings.
If, for example, you're more likely to have customers with several hundred or thousands of InvoiceLines and you only need those in very specific circumstances, then it seems very logical to split them up in the way you mention.
However, if you almost always need the InvoiceLines, and you're only usually talking 10 instances, then it makes more sense to always send them together.