I'm not sure I agree with removing the word Repository from UserRepository. Sure, if you look at what it does (methods or implementations), you realize it's a repository. But for that you have to look into the details. If it's in the name you save yourself a lot of time as you don't need to look into it to know what it does.
He shows both hiding the identity (id) and use SwedishPerson as an identity instead, but he also shows the repository IUsers query by the integer id... Which appears self-contradicting. Also, I personally don't like the WithXXX naming of methods in IUsers. "With" has been widely as a name for methods in immutable objects, especially since with records and 'with' keyword. But I still like the talk and the principles he talks about are good.
14:00 Ha! This is exactly my saying. DDD is in the end good OO and best packaged as hexagonal. And for the most part, DDD is an implementation detail of the model.
Putting validation into your domain models is a violation of separation of concerns. By this logic all your domain logic could be within your domain models, since the same reasoning can be applied. "if I have my domain logic outside of my model then the model can be used in invalid ways".
Not really, You have rules of what can come into your application. But you can also avoid an invalid domain model to be generated. Say that I have a Customer. In the API, I can enforce that a name has to be given. But I can also avoid creating a Customer with a negative age. A lot of time correct encaptulation gets lost due to "Seperation of concerns". Resulting an in aenemic domain model with transaction scripts and a of of loose code to validate stuff that either gets writen twice or never called the second time. Seperation of concerns should be renamed to "Seperation of incoherent concerns"
Kind of chaotic talk, but I liked it a lot! Look forward to reading the Blue Book. 💙
This talk is brilliant and it has been featured in the latest issue of 💥Tech Talks Weekly. Congrats Chris 👏
I'm not sure I agree with removing the word Repository from UserRepository. Sure, if you look at what it does (methods or implementations), you realize it's a repository. But for that you have to look into the details. If it's in the name you save yourself a lot of time as you don't need to look into it to know what it does.
He shows both hiding the identity (id) and use SwedishPerson as an identity instead, but he also shows the repository IUsers query by the integer id... Which appears self-contradicting.
Also, I personally don't like the WithXXX naming of methods in IUsers. "With" has been widely as a name for methods in immutable objects, especially since with records and 'with' keyword.
But I still like the talk and the principles he talks about are good.
14:00 Ha! This is exactly my saying. DDD is in the end good OO and best packaged as hexagonal. And for the most part, DDD is an implementation detail of the model.
Putting validation into your domain models is a violation of separation of concerns. By this logic all your domain logic could be within your domain models, since the same reasoning can be applied. "if I have my domain logic outside of my model then the model can be used in invalid ways".
Not really, You have rules of what can come into your application.
But you can also avoid an invalid domain model to be generated.
Say that I have a Customer. In the API, I can enforce that a name has to be given.
But I can also avoid creating a Customer with a negative age.
A lot of time correct encaptulation gets lost due to "Seperation of concerns".
Resulting an in aenemic domain model with transaction scripts and a of of loose code to validate stuff that either gets writen twice or never called the second time.
Seperation of concerns should be renamed to "Seperation of incoherent concerns"
Mourning
You should google it to understand what you just wrote 😲
Afternoon