I'm having an issue with naming of my types, generally it applies to all of my projects.
I'm working with CQRS and many times i have different layers of my application that refer to similar 'context' of a data.
For example i have a Player context which is spread across query model, write model, domain model etc.
Basically my question is that if some class/struct/data type is referring to specifically 'Query' type, should i name it as PlayerQuery or QueryPlayer.
From my understanding the 'PlayerQuery' implies that it is a query of a player data, on the other hand 'QueryPlayer' implies some kind of 'Query' behavior.
It has been quite a while when i started coding but i still struggle with properly naming things.
It feels like the 'PlayerQuery' is better approach here.
Are there any books or online resources where i could tackle this issue?
Thanks much
It has been quite a while when i started coding but i still struggle with properly naming things.
A great quote that is relevant here 😋 :
There are only two hard things in Computer Science: cache invalidation
and naming things.
-- Phil Karlton
You are having this problem because you are trying to approach the problem with a CRUD mindset, whereas CQRS (or CQS) advocates focusing on the actual interaction. Even when different parts of the application share player context, the reason for its usage will be different.
As examples, you will be:
Querying for a paginated list of players
Asking for a single player's detail
Saving an individual player's data
Bulk-updating an attribute in multiple player details
In each of these interactions, you should take the interaction itself as a cue to name the Query/Command/DTO object.
So the data class names could be:
PlayersList
PlayerDetailForQuery
PlayerDetailForSave
PlayerDetailsForBulkUpdate
An improvement would be to suffix each class name with the type of object:
PlayersListParams
PlayersListResult
PlayerRow (or) PlayerItem (or) PlayerDetail
PlayerEvent
PlayerSpecification
The best implementation would be to combine the interaction with the type of object:
FetchPlayerListParams
FetchPlayerListResult
GetPlayerDetail
BulkUpdatePlayerParams
SavePlayerCommand
PlayerSavedEvent
The most important thing is, once you choose a convention (like Detail instead of Item or Row), be consistent in its usage all over the code.
Related
based on the four layer MOF structure, I'm currently working on a model (in fact a UML class diagram) at M1 level. However, I observed that some parts of the meta model are highly depending on references to certain classes, which may may differ depending on the use case. Therefore, I created a meta model on the M2 level, which allows users to define the variable parts of the M1 Model, which again can then be generated and incorpareted in the M1 model. The following images tries to depict that:
A resulting M1 model example would then look like that:
As switching between the different levels can be a little bit confusing, I wonder if this approach is per se possible and UML conform? Furthermore, is there a notation for the "generated instances" relation in Figure 1 by chance? Within the MOF spec, <<merge>> or <<import>> is for example used, which maybe fit in for that purpose.
Probably your question is too broad to give a concise answer. However, here's my advice when dealing with meta models: I found that people hardly have an idea why you need a meta model at all and it takes quite some time to convince them starting to create one. Even with so called UML pros. Now, with that in background, it's evident that modelers who shall use the meta model might have even more difficulties dealing with it. This leaves just one way: keep it simple. And that's what I did in the past. Introducing a meta model with just really the basics, concentrating on meta types, tagged values and some connectors. After a while, people really get used to it and appreciate working with the meta model. Only then there starts the need to switch to a version two, which is still static though.
Now, what you want looks like a version ninety nine. This would probably only work in a super model where you have some gurus floating on top of it all an provide a meta meta model. This will going to be interesting and I'd like to be part of that team. However, I doubt you will be able to get practicable results from it. My recommendation is that you stay with the static meta model. Everything else will likely lead you to nowhere.
I am studying hard DDD now. After months of studying, I found a contradiction between modeling and coding. As you know, DDD has the principle of "Domain 1st, Tech 2nd". However, there are "definite" constraints when moving the actual model into the implementation, for example:
Original model:
With the domain concept, posts are associated with multiple comments, and comments are an ordinary model that depends on the post. Moving this into code ...
class Post{
Integer postId;
String title;
String content;
String writer;
Collection<Comment> comments;
}
class Comment{
String content;
}
Like this... But if there are hundreds of millions of comments, there will be performance problems. According to the solution I have investigated, finally I change the original model as follows....
Revised model:
Also the code will change...
class Post{
Integer postId;
String title;
String content;
String writer;
}
class Comment{
Integer postId;
String content;
}
This revised model works well for me and I am satisfied with the solution. But I feel something inconsistent. It seems that the model is distorting due to technical constraints. If we show the first and second models to the domain experts and talk about the diagram, he or she will better understand the first model.
Am I misunderstanding about DDD concept? If so, give me some advice. Thank you.
One of the changes in mindset that come with Domain Driven Design is that your domain will constantly evolve with changes to your understanding of the domain. It is not just that the domain will evolve, but your understanding and perception about it will evolve, as well.
What you are running into right now, in my opinion, is trying to rationalize the design based on the loading of one or more entities into an aggregate by looking at it from how it is persisted. This common parent and child relationship feels natural, because it is the way that most of us have done things in the past. Even from a DDD perspective, it is easy to get caught up in the "Comments can't exist without Posts" paradigm.
This comes down to the fact that you are modelling based upon data inside of the domain, instead of use cases. Look at it this way... Posts are not simply a collection of Comments. Instead, a Comment refers to a specific Post. The nuance sounds minor, but it has broad-reaching consequences. When modeled in this fashion, it matches your revised model - and it is completely and totally fine. The only thing you need to change is your mindset, being that Comment can be considered an Aggregate, just as a Post is. They both are going to have use cases where the other one must exist, but at the same time, you need to see that you are unlikely to do something where both are impacted as part of the same use case (outside of deletion of the Post).
To illustrate, consider this use case:
As a Writer, I want to be able to edit the Content of my Post.
Your new model actually effectively supports that. Instead of looking at the relationship, you are looking at how the domain is used. Should you load Comments for a Writer to edit? Without knowing your domain, I would still assume that you would not want to do so. There are use cases that will likely involve both Posts and Comments, and that is also fine. Since you have two Aggregates inside of a single Bounded Context, you will be able to support use cases that are solely based on Posts, solely based on Comments, or a combination of both.
In terms of the technical concerns, you mention "hundreds of millions of comments". I assume that you mean system-wide, and not for a single Post? Assume that you have an active post, and that it sees 20k comments in its lifetime. For a properly designed and optimized database, this should still not be an issue. When it becomes an issue, if it ever does, it can be further addressed by additional changes to the technology used, as opposed to changing the domain. You can look at things like caching strategies (outside of the domain, since that is an application concern and not a domain concern), external indexes, eventual consistency, etc.
Highly recommend taking a read through Vaughn Vernon's "Effective Aggregate Design" series of articles, if you have not already:
Effective Aggregate Design
Additionally, his excellent book "Implementing Domain-Driven Design", is a must-read, in my opinion. While the Evans material is essential, it is more like the theoretical concepts; whereas the Vernon material talks about how to put the concepts into practice and what the implications of those decisions are.
As an addendum, like plalx points out in the comments below. None of this is meant to be a generalization about Posts and Comments in general, but explicitly how they apply to your domain, as it has been described to us and what could be inferred from your models. Posts and Comments will likely behave differently for others, because others will have distinct use cases. Even within your own domain, should Posts and/or Comments exist in a different context, they could behave differently. Above all else, try and make sure that everything you add to your domain model (in general) is added because of a specific and direct use case. It is tempting to simply start data modeling, but you will start to find yourself trying to force use cases into the domain model. Domain modeling should not be a finite process, or a single step in the process. Be willing and able to adapt to changes in understanding or changes to the way that the business changes its overall operational strategies over time.
One pitfall I notice about people entering the DDD world is that they visualize their ARs as source of READ operations as well. So, many times they tend to "model" the ARs and its entities/value objects in a way that "appeals" a DTO that is meant to hydrate the UI.
In your case, I would make Post an AR and Comments another AR. Adding a comment shouldn't require to instantiate Post at all. Editing a Post shouldn't require to 'load' the comments at all.
Use an independent mechanism to project your post/comments into a POCO/DTO class that may make sense to have a collection of comments in your post.
Does it make sense?
Well this time the question I have in mind is what should be the necessary level of abstraction required to construct an Aggregate.
e.g.
Order is composed on OrderWorkflowHistory, Comments
Do I go with
Order <>- OrderWorkflowHistory <>- WorkflowActivity
Order <>- CommentHistory <>- Comment
OR
Order <>- WorkflowActivity
Order <>- Comment
Where OrderWorkflowHistory is just an object which will encapsulate all the workflow activities that took place. It maintains a list. Order simply delegates the job of maintaining th list of activities to this object.
CommentHistory is similarly a wrapper around (list) comments appended by users.
When it comes to database, ultimately the Order gets written to ORDER table and the list of workflow activities gets written to WORKFLOW_ACTIVITY table. The OrderWorkflowHistory has no importance when it comes to persistence.
From DDD perspective which would be most optimal. Please share your experiences !!
As you describe it, the containers (OrderWorkflowHistory, CommentHistory) don't seem to encapsulate much behaviour. On that basis I'd vote to omit them and manage the lists directly in Order.
One caveat. You may find increasing amounts of behaviour required of the list (e.g. sophisticated searches). If that occurs it may make sense to introduce one/both containers to encapulate that logic and stop Order becoming bloated.
I'd likely start with the simple solution (no containers) and only introduce them if justified as above. As long as external clients make all calls through Order's interface you can refactor Order internally without impacting the clients.
hth.
This is a good question, how to model and enrich your domain. But sooo hard to answer since it vary so much for different domain.
My experince has been that when I started with DDD I ended up with a lots of repositories and a few Value Objects. I reread some books and looked into several DDD code examples with an open mind (there are so many different ways you can implement DDD. Not all of them suits your current project scenario).
I started to try to have in mind that "more value objects, more value objects, more value objects". Why?
Well Value objects brings less tight dependencies, and more behaviour.
In your example above with one to many (1-n) relationship I have solved 1-n rel. in different ways depending on my use cases uses the domain.
(1)Sometimes I create a wrapper class (like your OrderWorkflowHistory) that is a value object. The whole list of child objects is set when object is created. This scenario is good when you have a set of child objects that must be set during one request. For example a Qeustion Weights on a Questionaire form. Then all questions should get their question weight through a method Questionaire.ApplyTuning(QuestionaireTuning) where QuestionaireTuning is like your OrderWorkflowHistory, a wrapper around a List. This add a lot to the domain:
a) The Questionaire will never get in a invalid state. Once we apply tuning we do it against all questions in questionaire.
b) The QuestionaireTuning can provide good access/search methods to retrieve a weight for a specific question or to calculate average weight score... etc.
(2)Another approach has been to have the 1-n wrapper class not being a Value object. This approach suits more if you want to add a child object now and then. The parent cannot be in a invalid state because of x numbers of child objects. This typical wrapper class has Add(Child...) method and several search/contains/exists/check methods.
(3)The third approach is just having the IList exposed as a readonly collection. You can add some search functionality with Extension methods (new in .Net 3.0) but I think it's a design smell. Better to incapsulate the provided list access methods through a list-wrapper class.
Look at http://dddsamplenet.codeplex.com/ for some example of approach one.
I believe the entire discussion with modeling Value objects, entities and who is responsible for what behaviour is the most centric in DDD. Please share your thoughts around this topic...
I am 80% sure I should not be asking this question because it might come across as negative and I mean no disrespect to anyone, especially the author of this book. I have seen several posts recommending this book and its companion project. I have not read the book, but I have spent a few hours today studying the project. And while it does look very complete, I am having a very hard time with how much the details of various things are scattered around. I am struggling in my own designs with how much I have to change if an entity changes, and this project does not make me very comfortable as a solution.
For example, there is a Employee object that inherits from a Person. Person has a constructor with first-name, last-name, etc. and therefore, so does Employee. Private to Employee are members for first name, last name, plus public properties for the same.
There is an EmployeeFactory that knows about both Employee and Person properties, as well as the SQL column names (to pull values from a reader).
There is an EmployeeRepository with unimplemented PersistNewItem and PersistUpdatedItem methods that I suspect, if implemented, would build SQL for INSERT and UPDATE statements like I see in CompanyRepository. These write the properties to strings to build the SQL.
There is a 'Data Contract' PersonContract with the same private members and public properties as Person, and an EmployeeContract that inherits from PersonContract like Employee does Person, with public properties mirroring the entities.
There is a static 'Converter' class with static methods that map entities to Contracts, including
EmployeeContract ToEmployeeContract(Employee employee)
which copies the fields from one to the other, including Person fields. There may be a companion method that goes the other way - not sure.
I think there are unit tests too.
In all I count 5-10 classes, methods, and constructors with detailed knowledge about entity properties. Perhaps they're auto-generated - not sure. If I needed to add a 'Salutation' or other property to Person, I would have to adjust all of these classes/methods? I'm sure I'd forget something.
Again, I mean no disrespect and this seems to be a very thorough, detailed example for the book. Is this how DDD is done?
Domain Driven Design is really simple. It says: make your Model classes mirror the real world. So if you have Employees, have an Employee class and make sure it contains the properties that give it its 'Employee-ness'.
The question you are asking is NOT about DDD, but rather about class architecture in general. I think you're correct to question some of the decisions about the classes you're looking at, but it's not related to DDD specifically. It's more related to OOP programming design patterns in general.
DDD s new enough (at least in some senses) that it may be a little early to say exactly "how it's done." The idea's been around for a fair long while, though, although we didn't make up a cool name for it.
In any case, the short answer (IMAO) is "yes, but...." The idea of doing a domain-driven design is to model the domain very explicitly. What you're looking at is a domain model, which is to say an object-oriented model that describes the problem domain in the problem domain's language. The idea is that a domain model, since it models the "real world", is relatively insensitive to change, and also tends to localize change. So, if for example your idea of what an Employee is changes, perhaps by adding a mailing address as well as a physical address, then those changes would be relatively localized.
Once you have that model, though, you have what I maintain are architectural decisions still to be made. For example, you have the unimplemented persistence layer, which might indeed be simply construction of SQL. It could also be a Hibernate layer, or use Python pickling, or even be something wild like a Google AppEngine distributed table structure.
The thing is, those decisions are made separately, and with other rationales, than the domain modeling decisions.
Something I've experimented with to some good result is doing the domain model in Python and then building a simulator with it instead of implementing the final system. That makes for something the customer can experiment with, and also potentially allows you to make quantitative estimates about the things the final implementation must determine.
to me, what makes DDD different from "mere" model-driven design is the notion of "aggregate roots", i.e. an application is only allowed to hold references to aggregate roots, and in general you will only have a repository for the aggregate root class, not the classes that the aggregate root uses
this cleans up the code considerably; the alternative is repositories for every model class, which is "merely" a layered design, not DDD
Im new to working with Domain Models so forgive me for asking an elementary question.
If a Domain Object has a 1-many relationship with another Domain Object but logic that uses the first object works with only a subset of that objects related objects, what is the best way to expose this subset?
For example, say a Person is related to many Orders but some external logic needs to examine only the "Dispatched" Orders associated with a Person. Should the Person have a DispatchedOrders property, along with other properties for other subsets (such as CompletedOrders etc) or is this bad design? Assume for performance reasons I cant filter the objects in memory and must use SQL to pull back only the subset I'm interested in.
Thanks
If you're using SQL to find the set you're interested in, you're in a perfect world. Relational queries are all about finding that sort of thing. Find the perfect query, and then just figure out what the class of the result tuples are, i.e., an object for each result tuple, and process them appropriately.
In your example, you want a set of "Dispatched Orders", which whatever person information necessary attached to each one.
I think you have the right idea - DispatchedOrders would tell me precisely what collection of object you are returning to me. As Curt said, you are in good spot as you can use SQL / stored procedure to fetch your data.
One caveat - be sure that the domain matches the business process and is not an interpolation of you understanding of that process. That is - why does a person have primacy over an order and what corner are you painted into when you construct other objects. Does a line-item contain an order as well, and does this lead to object bloat? Discussions with your client should help shape the answer.
Rob Conery of SubSonic fame has a good discussion of these types of issues. It's worth listening to.