I just have started to learn DDD. So I apologise for silly question...
So I have the Post entity. It looks fine. But it should have tags.
In code it looks like this (ruby code):
class Post
attr_reader :tags
attr_reader :title
attr_reader :text
# ...
end
class Tag
attr_reader :name
attr_reader :description
# ...
end
Tags aren't make a sense as entity. I don't need tag itself.
But how should I to implement repository for post?
I have found 2 variants:
1.
Build tags in same repository. Like this:
# PostRepository
def find(id)
# getting post data from storage here
# getting tags data
Post.new(title, text, tags_data.map { |tag_data| Tag.new(tag_data[:name], tag_data[:description]))
end
But it looks ugly. Can't clearly say why.
2.
Make separate repository for tags.
# PostRepository
def find(id)
# getting post data from storage here
Post.new(title, text, tag_repository.find(tag_ids)) # or tag_names or tag_something
end
Looks better. But is it fine to make separate repository for value-objects?
What is the right way according DDD?
UPD:
In other hand, I have to get all available tags. And I never have to change tag with posts. And tags' name looks like identity. Maybe I'm fundamentally wrong? Maybe tag is entity?
UPD2:
This problem shows me that my design skill is very poor.
Because of it, there is two question in my one.
They are:
What is right way to build value object inside entities' repository.
How to see the difference between value and entity in my problem.
After all it looks clear. According the specified conditions, tag is value. And it's ok that it's builded by Post's repository.
But this conditions is result of poor analize. If I could look wider, I would see that tag has it's own life cycle. Though, in context of post, tags are immutable.
Tag is most probably just a regular value object in your domain. Tag could be an entity, if it had its own lifecycle. Frankly, I don't think that's the case in your domain, as you can replace each tag with another copy with the same properties.
You can add methods to query tags to your domain repository. It's not a violation of DDD aggregate rules. Aggregates are really about consistency - your repositories should not return parts of your aggregate if you can modify them outside of aggregate context. However, you can explicitly return value objects of your aggregates just for read purposes (e.g. collecting all tags of all posts within selected date range). Besides that, query methods should be placed inside repository for the sake of efficiency. That being said, in your case probably the best solution is to use separate read model (using e.g. nosql db) following CQRS principles. This way you have the model explicitly adjusted to your query needs, so it can very efficient.
Related
I am making a class diagram for Class/Course Registration where students have to first register their course then select their class schedules (timetable)
I am unsure if I can have CourseRegistration and ClassRegistration table like that. The reason why I made it like that is, a student can register for a course but doesnt register to a class directly. so they can wait few days and then only register. So I have to make sure the course registration is saved in the database.
Thank you for all the help
PS: pls don't mind my attributes, they're just a draft.
Your business logic for the registration process (register both for a course and a corresponding class) is too complicated. Normally, one would only register for a class, which would then imply taking the corresponding course.
Also, what does "ClassSchedule" stand for? Is an instance of a "ClassSchedule" a class meeting?
Since your model is supposed to define a design (of database tables and of, e.g., Java classes), each entity class should have an ID attribute defined, which is expressed in UML with the keyword "id" in curly braces appended to the attribute declaration. Having "ID" in the attribute names is not a formal declaration. Also, an ID attribute seems to be missing for ClassSchedule.
Yes, that's fine this way. You could alternatively use the association class notation like this:
Some side notes:
labeling associations is not that helpful except you are on a business level analysis. Rather use role names on either end where appropriate.
Edit I somehow overlooked that you're designing tables. So my previous comment
remove all the id attributes. Each object will have its unique id assigned by the runtime system. Use such an id only if it's of public meaning (e.g. a passport id or a student's registration number). And then use that specific name (e.g. passportId) rather than a <class>id.
goes just for basic class design. If you already have a (derived) table design you can just go with those ids.
In an application that uses event sourcing is it acceptable to have aggregate-wide events?
Consider a contrived example of a blog application that provides the ability to create posts and add and remove simple tags (post would be the aggregate root).
This might result in the following events:
PostCreated: postId, "title", "content"
TagAdded: postId, "Foo"
TagAdded: postId, "Bar"
TagAdded: postId, "Baz"
TagRemoved: postId, "Bar"
Replaying the above event stream would result in a post with a title, content and two tags ("Foo" & "Baz").
Now imagine the user interface only allows you to select existing tags whilst creating a post and doesn't accept free text; only privileged users have the ability to update the master list of tags.
Now when a privileged user creates a new tag, a corresponding event needs to be created so that a) the information is actually stored in the event storage and b) at some point the read model is updated so that users creating blog posts can select the new tag in the UI.
Having an event that looks like TagCreated: postId, "NewTag" doesn't seem right to me as the information does not directly apply to a single post.
Considering that in this case the information does not warrant it's own aggregate root and will only be used in this bounded context I would expect an event along the lines of:
TagCreated("NewTag")
These events would be stored in the event storage using the same aggregate id as the previous set of events for a specific post but without an id for the specific aggregate instance.
So far this sounds like a logical way to handle the problem but was wondering if I am missing anything obvious by approaching it this way.
IMHO you're complicating your life unnecessary. Domain events are usually available cross bounded context and they should be associated with an aggregate root (AR) by referencing its id.
In your example, I'd consider Tag to be a value object, so it would require a post id. But if you want the Tag to be available as itself, then it would be an AR and so, the event would have a TagId property.
Btw, a domain event is a DTO, meant to be available everywhere, they're not a domain detail that needs to be encapsulated in an aggregate.
I think you missed the concept "tag catalog" or something like that. It could have a single aggregate (or perhaps you will sometimes have several catalogs for different user groups or something like that) with the catalog as the root, containing all the tags as value objects.
I'm developing an application with Domain Drive Design approach. in a special case I have to retrieve the list of value objects of an aggregate and present them. to do that I've created a read only repository like this:
public interface IBlogTagReadOnlyRepository : IReadOnlyRepository<BlogTag, string>
{
IEnumerable<BlogTag> GetAllBlogTagsQuery(string tagName);
}
BlogTag is a value object in Blog aggregate, now it works fine but when I think about this way of handling and the future of the project, my concerns grow! it's not a good idea to create a separate read only repository for every value object included in those cases, is it?
anybody knows a better solution?
You should not keep value objects in their own repository since only aggregate roots belong there. Instead you should review your domain model carefully.
If you need to keep track of value objects spanning multiple aggregates, then maybe they belong to another aggregate (e.g. a tag cloud) that could even serve as sort of a factory for the tags.
This doesn't mean you don't need a BlogTag value object in your Blog aggregate. A value object in one aggregate could be an entity in another or even an aggregate root by itself.
Maybe you should take a look at this question. It addresses a similar problem.
I think you just need a query service as this method serves the user interface, it's just for presentation (reporting), do something like..
public IEnumerable<BlogTagViewModel> GetDistinctListOfBlogTagsForPublishedPosts()
{
var tags = new List<BlogTagViewModel>();
// Go to database and run query
// transform to collection of BlogTagViewModel
return tags;
}
This code would be at the application layer level not the domain layer.
And notice the language I use in the method name, it makes it a bit more explicit and tells people using the query exactly what the method does (if this is your intent - I am guessing a little, but hopefully you get what I mean).
Cheers
Scott
We're working on a new project (re-writing existing app), and I'm running into problems with my domain model / repository design.
Here is a (simplified) version of two key portions in our domain model:
As you can see, I have an abstract concept of a Post, which can be things like a Review, a Discussion, a Photo, a Video, etc. Posts can also have comments.
I also have a abstract concept of a Location, which are obviously things like Streets, Cities, Neighbourhoods, etc.
Now, this naturally looked to me as two clear aggregate roots.
So I created two repositories, one called PostRepository, and another called LocationRepository.
This was all working fine, I can add/get any type of Post (or comment), and add/get any type of Location via one of these two repositories.
But now im in the scenario of a "landing page" for a City (for example).
On this page, I need to basically show "all posts for this location".
How is that defined? Well, a Post can be (optionally) tagged at a Location. Implementation detail, so I don't want to go too deep into data (as that's not what DDD is about), but essentially there is geospatial intelligence to work out which posts are contained in a particular location by the shape file of the location, and the latitude/longitude of the tagged Post.
But how can I retrieve this information without crossing the boundaries?
Which repository do I use? Do I need a new one?
If it matters (or for the curious), this is a web application (ASP.NET MVC), with a SQL Server 2008 database and Entity Framework 4.0.
If you need any clarification, let me know.
EDIT
We currently use a modified version of the Specification pattern in order to retrieve domain models.
For example, this is the code in our BLL to retrieve all Review's where Score >= 4:
var reviews = postRepository // GenericRepository<Post>
.Find() // IQueryable<Post>
.OfType<Review>() // IQueryable<Review>
.Where(x => x.Score >= 4)
.ToList(); // List<Review>
But now I need some code like this:
var reviews = postRepository
.Find()
.OfType<Review>()
.Where( //lat long, or Locations FK )
.ToList();
The problem is I don't know how to do the above query without adding an intermediary join-entity (LocationPost - as it's a many to many), and add a FK to the Post domain model to that.
But by doing that, I am crossing the aggregate boundaries - aren't I?
Why is this a problem?
According to Evans in his book, one AR may very well reference another AR.
(You may not however reference a child element in an AR from another AR)
Also, are locations really aggregate roots?
The definition of an aggregate root is that it acts as a boundary of concistency.
Does that fit the definition of a location?
I'd say a location is a value object.
There are pretty much two camps here regarding repositories and AR associations:
One that says that all aggregate roots have to be fetched through their respective repository, and AR's should use soft relations, eg ID's between them
And one that says that aggregate roots may very well fetch other associated aggregate roots and that a repository is merely a way to find aggregate roots.
I would bind post to the location at creation time so that for each location I can get (through a repository) a list of associated posts. It would look like this:
Creation:
var p = new Post(latitude, longitude);
var locations = locationRepository.FindByCoordinates(latitude, longitude);
foreach (var l in locations)
{
l.AssociatePost(p);
}
session.Save(p);
Retrieval:
var associatedPosts = postRepository.FindByLocation(locationId);
foreach (var p in associatedPosts)
{
Display(p);
}
Under the hood, the association between posts and location would be implemented as a many-to-many table relationship. There is one problem with this solution: adding a new location requires to scan all the posts and assign them to the new location (if applicable).
Hope that helps.
Let's say you used the Specification pattern, could you build a Post Specification using a Location object? Then you just pass the Specification to your Post Repository, and get back the result.
In the context of Domain Driven Design, is a StackOverflow tag (ie. ddd ) a value object or entity?
EDIT:
Imagine, that you have to build SO website. How would you consider 'tag'?
To expand a little on awhite's answer
a tag is a value type
Why?
Because it doesn't make sense to have
var tag1 = new Tag("DDD");
var tag2 = new Tag("DDD");
Assert.AreNotEqual(tag1, tag2);
clearly they should be equal to each other because a tag has no identity except for its label. Questions and answers on the other hand are definitely entities
SO tag is most likely an entity. Tags can be created, merged, deleted and renamed. There are features like 'similar tags', user's tags etc. Some of these functions, especially life cycle, will require an identity. Classic DDD example where Person that changes his/her name is still the same person, the same identity. The same with tags where user can decide to rename "domain-driven-design" to "DDD" and it will still be the same thing. Tags also need additional attributes like tag.Id, tag.Name, tag.CreatedOn, tag.CreatedBy, tag.Locked etc. There would probably be a corresponding tags repository that can enforce name uniqueness rule.
To summarize, SO Tag is not a DDD Value Object because it is mutable and has a life cycle. More importantly, Tag is not only a characteristic of a Question (this is what I think was overlooked by other answers). It participates in a lot more relationships than that. In other words, Tag is more than just a sum of its attributes, it also has 'conceptual identity'. On the other hand TagName is a perfect example of Value Object. Its only purpose in life is to describe another entity (Tag). TagName is nothing more than just a string that may have a few built in rules like max length and case insensitive comparison. It may also make sense to simply use String instead.
Code that displays questions may use something like this:
IList<TagName> tags = question.GetTags();
Code that tags the question can look like this:
void TagQuestion(Question q, TagName tagName) {
Tag tag = _tagsRepository.FindByName(tagName);
if (tag == null) {
tag = CreateNewTag( /* capture creator, date, other rules*/);
}
q.AddTag(tag);
}
Just some additional considerations: Tags can be normalized, "DDD" should be equal to "ddd" and "DdD", and in most tag systems, spaces get replaced with "_" underscores. Also I guess the creator will be tracked for the badge system.