I'm not quite sure of the most elegant solution for what I am trying to do.
I have a page which lists music listings, there can be thousands of these so they are paged in batches of 20, I also have 4 links at the top of the page to change the way these listings are ordered.
The sort by properties could be located on different entities such as Audio.AudioStats.NumComments or Audio.Artist.NumProfileViews.
I am using the repository pattern, and a service layer. My controllers can only access the service layer, then the service layer accesses my repositories.
I can do the paging fairly easily, i simply pass in my current page, and the page size to my data layer...but how would i safely let the user decide on the ordering of my entities.
I am using S#arp Architecture 1.5.2 if that makes any difference.
Thank you in advance.
You are going to have to map the users' desires to an order by clause somehow.
Presumably you're doing something like skip(n).take(m) which will need an orderby() clause too.
Given that you have a fixed set of (known) possibilities, you can map those to an enum or similar which you then translate to the relevant orderby() call.
This means you don't expose the properties at the UI layer but only pass through the intent to the repository layer (as a Sortby.ArtistProfileViews value or whatever). What how that intent is mapped to the properties on you domain objects is isolated in your repository layer.
Related
I am using strongly typed ids in my domain model, mostly following the guidance from Andrew Lock at:
https://andrewlock.net/using-strongly-typed-entity-ids-to-avoid-primitive-obsession-part-1/
These ids, e.g. ProductId, CustomerId, etc. are declared in the Domain Model.
My question is about exposing these to consumers of the Application layer. At the moment, an API controller could create a Command to send to the Application layer. These commands also needs to use Ids. My current implementation in the Command objects is use the primitive type, Guid, and then create a Strongly Typed Id when calling methods on the Domain Model.
However, it makes sense to extend the control offered by using strongly typed ids to communication between the API Controller and the Application Layer. But, I do not want my API Controllers to have a reference to the Domain Model (which is where the Strongly Typed Ids are declared at the moment).
How to go about this?
Declare a similar set of Strongly Typed Ids from the Application Layer. But this would still need a translation between the Application declaration and the Domain Model declaration before calling methods in the Domain.
Move the declaration of Ids into a 'public' module that both the API and Domain Model can reference. But this would mean some leakage of Domain Model dependencies to the API Controller dependencies and any change in my Domain Model approach may impact the API Controllers, which is not desirable.
The ask seems reasonable, but neither of the above solutions feel optimal. Any thoughts?
Having reviewed Vaughn Vernon's book "Implementing Domain-Driven Design":
https://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=asc_df_0321834577/
I have followed the advice on page 580, which is basically "be pragmatic".
Specifically,
For Ids and any other value object that I consider pretty 'fixed' I have chosen to use a shared kernel that API, Application and Domain layers can use (i.e. option 2 from my question).
For other, potentially more complex, value objects that may contain additional business logic specific to the Domain and may be more volatile in response to business change, then I am using option 1 from my question and creating a slimmed down (DTO) version for exposing from the Application and performing mapping from those to the Domain Model versions.
In DDD, repositories are used to perform serialization and de-serialization of aggregates, e.g. by reading and writing to a database. That way, aggregates can contain purer business logic, and won't be coupled to non-domain-specific persistence strategies.
However, I wonder why repositories are always described as being used for aggregates specifically. Isn't it equally motivated to use it for all entities?
(If this is only a matter of the fact that all plain entities can be seen as aggregate roots with zero children, please notify me of this, and the question can be buried.)
I wonder why repositories are always described as being used for aggregates specifically. Isn't it equally motivated to use it for all entities?
Because aggregates are the consistency boundaries exposed to the application layer.
Which is to say that, yes, the repositories are responsible for taking the snapshot of state from the data store, and building from it the graph of entities and values that make up the aggregate.
The API of the repository only exposes an aggregate root, because that defines the consistency boundary. Instead of allowing the application to reach into an arbitrary location in the graph and make changes, we force the application to communicate with the root object exclusively. With this constraint in place, we only need to look in one place to ensure that all changes satisfy the business invariant.
So there's no need to develop a repository for each type of entity in your model, because the application isn't allowed to interact directly with the model on that fine a grain.
Put another way, the entities within the aggregate are private data structures. We don't allow the client code to manipulate the entities directly for the same reason that we don't implement lists that allow the clients to reach past the api and manipulate the pointers directly.
In cqrs, you do see "repositories" that are used for things other than aggregates -- repositories can also be used to look up cached views of the state of the model. The trick is that the views don't support modification. In the approach that Evans describes, each entity has one single representation that fulfills all of its roles. In CQRS, and entity may have different representations in each role, but typically only a single role that supports modifying the entity.
In DDD there are two kind of entities: Aggregate roots and nested entities. As #VoiceOfUnreason answered, you are not allowed to modify the nested entities from outside an Aggregate so there is no need to have a repository for them (by "repository" I'm refering to an interface for load and persist an entities state). If you would be allowed, it would break the Aggregate's encapsulation, one if the most important things in OOP. Encapsulation helps in rich domains, with lots and lots of models where DDD is a perfect fit.
I've been working with NHibernate for quite a while and have come to realize that my architecture might be a bit...dated. This is for an NHibernate library that is living behind several apps that are related to each other.
First off, I have a DomainEntity base class with an ID and an EntityID (which is a guid that I use when I expose an item to the web or through an API, instead of the internal integer id - I think I had a reason for it at one point, but I'm not sure it's really valid now). I have a Repository base class where T inherits from DomainEntity that provides a set of generalized search methods. The inheritors of DomainEntity may also implement several interfaces that track things like created date, created by, etc., that are largely a log for the most recent changes to the object. I'm not fond of using a repository pattern for this, but it wraps the logic of setting those values when an object is saved (provided that object is saved through the repository and not saved as part of saving something else).
I would like to rid myself of the repositories. They don't make me happy and really seem like clutter these days, especially now that I'm not querying with hql and now that I can use extension methods on the Session object. But how do I hook up this sort of functionality cleanly? Let's assume for the purposes of discussion that I have something like structuremap set up and capable of returning an object that exposes context information (current user and the like), what would be a good flexible way of providing this functionality outside of the repository structure? Bonus points if this can be hooked up along with a convention-based mapping setup (I'm looking into replacing the XML files as well).
If you dislike the fact that repositories can become bloated over time then you may want to use something like Query Objects.
The basic idea is that you break down a single query into an individual object that you can then apply it to the database.
Some example implementation links here.
We are using Lucene as the search server for data retrieval.
With this come certain complexities that I was unprepared for, not the least of which is managing relationships between objects.
I want to create a clean and simple POCO for our domain objects. These POCOs will contain related objects that I need for the UI, but no other fields (IDs defining these relationships, various other fields I simply don't need on the UI)
This means that I cannot directly translate Lucene's Hits collection into my UI-friendly POCOs and need some intermediary set of classes that will, at the least, contain IDs of related objects (stored in the same, or other indeces). I hesitate to call these DTO objects but for the sake simplicity I will call them that.
So I envision it working as follows:
Perform query in Lucene -> Hits collection
Iterate through Hits -> DTO collection
DTO collection -> [service to retrieve related objects, compose a POCO] ->
POCOs
Render a UI using the shiny simple POCOs
My fear in doing so is that I'll end up with Anemic Domain Model ( http://www.martinfowler.com/bliki/AnemicDomainModel.html ).
Is this a valid concern or am I on the right path?
I've ended up going the familiar to me pattern of a DTO. DTO has all the IDs - it is merely a CLR reflection of a record retrieved from Lucene.
I then map from DTO to a POCO in the service layer and use those objects to render the UI elements.
Does not feel slick, but it works.
Without any ID information in your POCOs, your design will likely suffer from anemia as there will just be an unconnected jumble of objects (which may not even fit all in memory at once). Also, it would seem to me that the lack of IDs would greatly interfere with caching and memoization (which help in not hitting the database every time you need an object). I have rarely had the luxury of assuming that all of my data will fit in memory all at once.
Take this simple, contrived example:
UserRepository.GetAllUsers();
UserRepository.GetUserById();
Inevitably, I will have more complex "queries", such as:
//returns users where active=true, deleted=false, and confirmed = true
GetActiveUsers();
I'm having trouble determining where the responsibility of the repository ends. GetActiveUsers() represents a simple "query". Does it belong in the repository?
How about something that involves a bit of logic, such as:
//activate the user, set the activationCode to "used", etc.
ActivateUser(string activationCode);
Repositories are responsible for the application-specific handling of sets of objects. This naturally covers queries as well as set modifications (insert/delete).
ActivateUser operates on a single object. That object needs to be retrieved, then modified. The repository is responsible for retrieving the object from the set; another class would be responsible for invoking the query and using the object.
These are all excellent questions to be asking. Being able to determine which of these you should use comes down to your experience and the problem you are working on.
I would suggest reading a book such as Fowler's patterns of enterprise architecture. In this book he discusses the patterns you mention. Most importantly though he assigns each pattern a responsibility. For instance domain logic can be put in either the Service or Domain layers. There are pros and cons associated with each.
If I decide to use a Service layer I assign the layer the role of handling Transactions and Authorization. I like to keep it 'thin' and have no domain logic in there. It becomes an API for my application. I keep all business logic with the domain objects. This includes algorithms and validation for the object. The repository retrieves and persists the domain objects. This may be a one to one mapping between database columns and domain properties for simple systems.
I think GetAtcitveUsers is ok for the Repository. You wouldnt want to retrieve all users from the database and figure out which ones are active in the application as this would lead to poor performance. If ActivateUser has business logic as you suggest, then that logic belongs in the domain object. Persisting the change is the responsibility of the Repository layer.
Hope this helps.
When building DDD projects I like to differentiate two responsibilities: a Repository and a Finder.
A Repository is responsible for storing aggregate roots and for retrieving them, but only for usage in command processing. By command processing I meant executing any action a user invoked.
A Finder is responsible for querying domain objects for purposes of UI, like grid views and details views.
I don't consider finders to be a part of domain model. The particular IXxxFinder interfaces are placed in presentation layer, not in the domain layer. Implementation of both IXxxRepository and IXxxFinder are placed in data access layer, possibly even in the same class.