1:10:15 Actually the repository is exactly the customer list you would pass if you didn't have a database, still. Repositories are a domain concept, they have nothing to do with the database, it's the collection of your entities, which can be in local memory (CPU cache, RAM, Disk) or remote (databases, remote disks). That's why the interface of them are in the domain layer, while the implementations are not. Of course in 99% of the domains the place where you store your entities aren't called "repositories", just like people responsible to do jobs related to some entity aren't called "Services", these are just generic names (that you should avoid when possible). For example, an isp/phone line company may lookup their phone numbers catalog to check for unique numbers to assign to a new customer. Or in your case, validate email uniqueness before changing it. "A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection." - Martin Fowler Great presentation anyway, love your content Vladimir Khorikov!
Also, call to repository requires passing correct parameters, which likely belong to domain anyway. If we chose to pass materialized instance to the entity's method, then there should be a check that passed value is relevant (e.g. its id is the same as in the reference entity holds.)
This is a disputed topic I know; but I disagree :). Do you know many Domain experts that use the notion of Repository ? No, it's an Application concern IMO, with the Use Cases. If you never have to "apply" a Domain Model then there's no need for saving or loading entities. The actual implementation of the Repository would belong to a DataAccess/infra layer. Martin Fowler's sentence still stands with this design: the Repository mediates between Domain and Data Access layers by depending on both; but for the sake of the use cases hosted in the Application layer.
@@fellowseb Thanks for disagreeing. Btw even I disagree with myself 1 year ago. I've learned that we shouldn't talk about "the domain" as if there was only one into play (as I did when I said "repositories are a domain concept"). What happens actually is that everything has a domain, and you should be separating them as modules inside your application, each one with its concern (all of them are important!). That being said, when you say: "Do you know many Domain experts that use the notion of Repository? None", I could point the catalog domain, which is the domain that registers stuff so they are trackable, and they do exist in the domain experts lives, with your system or not, they have to do it (obviously they don't call it Repository tho). What happens is that cataloging has a common thing between all entities, that is: record uniqueness ensurance, queries, add/removal... etc. This means this common aspect can be (and usually is) modeled with Generics. And that's very fair. If you look closer at List, IEnumerable, Arrays containers... they are all generic, right? I still stand mostly of what I said, though. """"Repositories""" are just another container for your entities, a custom one, they are no different (in interface) than a List, an Array, or any other container. That's also why I like to call them "EntityCollection", or more recently "EntitySet", because there can't be duplicates. I do think that they could belong to a "supporting" domain (an infra domain?), but infra just like you use C# (or any other language) primitives: ints, strings, lists... It would compose the infrastructure of your domain (this can sound harsh for the purists, but yeah your domain do depend on some trivial semantics to exist).
Outstanding! This video really helps clarify the concepts as I go through the O'Reilly book on DDD. Is there a GitHub repository to view a complete example?
If you give up encapsulation and choose purity, you end up also losing the purity. In the example you have to move part of the domain logic to the controller. This means the controller now _is_ part of your domain model implementation, and it refers to an out-of-process dependency (the repository). So you have now given up purity as well, by introducing an impure method into your domain model. By contrast, if you give up purity (ie. pass a reference to the repository into the domain model), you are not automatically giving up encapsulation - all the logic is still in one class.
DDD is not something that can be properly "nutshelled". It's rather dense and has a lot of different concepts which may lead to different interpretations and so on and so forth... definitely not a "nutshellable" thing lol. Vlad did great though -- showing code it's always more effective for comprehension, I think.
Great presentation. I am just confused by the idea of synchronizing data between contexts. Creating duplicity in data is considered bad practice isnt it?
Is caching data a bad practice? I think in this case you have your source of truth and your cache. if these bounded contexts were each a micro service, they would each have their own storage. You don't want to have to make a call to the Support microservice everytime the Sales microservice needs an attribute of the customer owned by the Support service. That said, in a monolith while I might have different classes in each context, I would probably store them in the same persistence object (table). At least that's how I see it.
![Hunxho - Ball Forever [Official Video]](http://i.ytimg.com/vi/nki9ZTF9Uls/mqdefault.jpg)
I strongly recommend Vladimir's Unit Testing Book.
Just a comment, this talk is pure gold 😊
Vladimir's content always deserves upvote. Great presentation.
Merci Monsieur Khorikov ! Very good presentation !
Great presentation and talk!
Thanks to Centric and Vladimir
Vlad makes learning DDD concepts very easy. Well done Vlad.
Great job Vlad!Excellent video!
Very good making Theory more practically relatable. Thanks much
Very nice discussion.. really enjoying. Thank you vlad
A fantastic presentation, many thanks!
Great presentation. Thank you!
1:10:15 Actually the repository is exactly the customer list you would pass if you didn't have a database, still. Repositories are a domain concept, they have nothing to do with the database, it's the collection of your entities, which can be in local memory (CPU cache, RAM, Disk) or remote (databases, remote disks). That's why the interface of them are in the domain layer, while the implementations are not. Of course in 99% of the domains the place where you store your entities aren't called "repositories", just like people responsible to do jobs related to some entity aren't called "Services", these are just generic names (that you should avoid when possible). For example, an isp/phone line company may lookup their phone numbers catalog to check for unique numbers to assign to a new customer. Or in your case, validate email uniqueness before changing it.
"A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection." - Martin Fowler
Great presentation anyway, love your content Vladimir Khorikov!
Also, call to repository requires passing correct parameters, which likely belong to domain anyway. If we chose to pass materialized instance to the entity's method, then there should be a check that passed value is relevant (e.g. its id is the same as in the reference entity holds.)
This is a disputed topic I know; but I disagree :). Do you know many Domain experts that use the notion of Repository ? No, it's an Application concern IMO, with the Use Cases. If you never have to "apply" a Domain Model then there's no need for saving or loading entities. The actual implementation of the Repository would belong to a DataAccess/infra layer.
Martin Fowler's sentence still stands with this design: the Repository mediates between Domain and Data Access layers by depending on both; but for the sake of the use cases hosted in the Application layer.
@@fellowseb Thanks for disagreeing. Btw even I disagree with myself 1 year ago. I've learned that we shouldn't talk about "the domain" as if there was only one into play (as I did when I said "repositories are a domain concept"). What happens actually is that everything has a domain, and you should be separating them as modules inside your application, each one with its concern (all of them are important!).
That being said, when you say: "Do you know many Domain experts that use the notion of Repository? None", I could point the catalog domain, which is the domain that registers stuff so they are trackable, and they do exist in the domain experts lives, with your system or not, they have to do it (obviously they don't call it Repository tho). What happens is that cataloging has a common thing between all entities, that is: record uniqueness ensurance, queries, add/removal... etc. This means this common aspect can be (and usually is) modeled with Generics. And that's very fair. If you look closer at List, IEnumerable, Arrays containers... they are all generic, right?
I still stand mostly of what I said, though. """"Repositories""" are just another container for your entities, a custom one, they are no different (in interface) than a List, an Array, or any other container. That's also why I like to call them "EntityCollection", or more recently "EntitySet", because there can't be duplicates.
I do think that they could belong to a "supporting" domain (an infra domain?), but infra just like you use C# (or any other language) primitives: ints, strings, lists... It would compose the infrastructure of your domain (this can sound harsh for the purists, but yeah your domain do depend on some trivial semantics to exist).
Thank you for explaining Kingdom Hearts 3D: Dream Drop Distance 😊
Thanx for russian subtitles
[1:40:17] Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#
Book by Scott Wlaschin
Outstanding! This video really helps clarify the concepts as I go through the O'Reilly book on DDD. Is there a GitHub repository to view a complete example?
If you give up encapsulation and choose purity, you end up also losing the purity.
In the example you have to move part of the domain logic to the controller. This means the controller now _is_ part of your domain model implementation, and it refers to an out-of-process dependency (the repository). So you have now given up purity as well, by introducing an impure method into your domain model.
By contrast, if you give up purity (ie. pass a reference to the repository into the domain model), you are not automatically giving up encapsulation - all the logic is still in one class.
The Customer example was not so sounding practically where it was mentioned to repeat the code
...a rather big nutshell :P
DDD is not something that can be properly "nutshelled". It's rather dense and has a lot of different concepts which may lead to different interpretations and so on and so forth... definitely not a "nutshellable" thing lol. Vlad did great though -- showing code it's always more effective for comprehension, I think.
Great presentation. I am just confused by the idea of synchronizing data between contexts. Creating duplicity in data is considered bad practice isnt it?
Is caching data a bad practice? I think in this case you have your source of truth and your cache. if these bounded contexts were each a micro service, they would each have their own storage. You don't want to have to make a call to the Support microservice everytime the Sales microservice needs an attribute of the customer owned by the Support service.
That said, in a monolith while I might have different classes in each context, I would probably store them in the same persistence object (table).
At least that's how I see it.
1:13h in - btw can you hear me? :D
very nice accent ))) Are they Russians, Ukrainians or Poles?