We should all thank the State of Texas for allowing Bogard to speak so openly about the development of these projects. The developer community as a whole benefits. Bogard as always a brilliant presenter.
Great to hear specifics about actual application of DDD to real life projects. I appreciate his honesty and humility about their initial experience; such maturity is really needed as we discuss implementations of all these newer patterns and practices. Thanks!
I'm amazed by Jimmy's honesty and openness both about the technical aspect of the project as well as about the legal system and how it works! great talk, thanks!
Thanks Jimmy! Mostly for being humble and admitting mistakes - really valuable for the public (and me) - and for sharing the insights in the more successful project. I have seen a project where many new techniques such as DDD, Event Sourcing, CQRS etc. was used at the same time and not fully understood by the team, and I presume there are many of those out there - of those that survived and made it to production :). and thanks to NDC for uploading!
Really the illustration of this: "If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort-but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. There’s this very long lag between what you might call the best practice in computing research over the years and what is able to leak out and be adapted in the much more expedient and deadline-conscious outside world."
i think at the end of the day there are 2 sides - you try and encapsulate and abstractify each entities ever evolving workflow, OR you create a powerful tool that molds into different use cases and the agency/companies adapts to it. the computer itself is not engineered specifically for any business, its just made in a way where it can be flexible enough to be molded into different scenarios. so the solution is something in between those 2 paths, you want it abstract enough to have large spread but also optimized for the specific sector/industry.
Really great case study - In UK , TOGAF enterprise architecture is common , its interesting to consider how this fits with domain driver design. In TOGAF 'views' and 'viewpoints' are the perspectives (reality slices) of the differering stakeholders
Jimmy dissing the blue book just at the end :p ... fantastic presentation and... explaining the whole workshop approach in discovering and figuring out knowledge. I am interested in how many diagrams and which kinds they had to use to map this out. I like the fact he points out so much the ubi lang and contexts, not the coding aspect of the whole problematic. And also... 0 value objects haha, I love that as it proves you do not need to be evangelistic at DDD but you can still make stuff work great. Amazing presentation Jimmy, thank you.
37:26 "Boss Hog sheriff or something". 🤣🤣 Maybe there was at least one other American in the room who grew up in the 80's and remembers Dukes of Hazzard.
I suspect your difficulty of using the tactical patterns comes from not having routine with them. They don't, in fact, require to be used. They provide a taxonomy of what you'll inherently create as you proceed with implementation. They are helpful with not mixing stuff. You know you need a struct. (It will be a full class in Java without JEP 169, but that doesn't make any difference.) You need to identify whether that struct is an entity or a value object, in order to know how you'll handle instantiation and mutation. Putting a label on the type when you create it helps with this. But even without the label, you should still take care of such aspects.
Not necessarily. DDD doesn't prescribe the structure of the binaries, i.e. many small executables or one large executable. In theory at least, you can put all the code of all services in a single binary too, without affecting the working of the software. What DDD prescribes is dealing with each bounded context in isolation on the solution side. You can do this equally well with putting each bounded context into its own module in a monolith, or putting each bounded context in a separate binary executable. The reason to go with many small binaries has more to do with operational concerns than with design/architecture. You can deploy independently (as long as you stick to well defined, agreed upon interfaces), you can test independently and perform most of the system tests at the service level, you can scale, monitor and audit each service independently. All these aspects, however, don't affect what and how each business domain concern is handled.
In principle, one repo is responsible for one kind of entity. Many repos for one entity type create confusion. But you are right, that class (well, interface) is a monstrosity. What I'd do is introduce a domain-specific language for queries at the application level. It can be graphical (a dialog with lots of checkboxes, radios, text fields, buttons and whatever, for example), but it should dynamically create queries - which you can store as such to run repeatedly - rather than hard-code a ton of different queries. Chances are that many different users will want their own handful of very specific queries, maybe even with user-specific parameters. A DSL allows them to easily define their own queries, rather than collecting and implementing the needs of many users and never satisfying all.
That wasn't the only "shot" he took at the MIBs in the video. Jimmy...you can say it's a joke but your thoughts shine through loud and clear throughout the presentation :). Just because you went on ride alongs doesn't mean you have positive overall feelings about the group you are riding with.
@@jlrosine An important part of being an American is freedom of expression. You are allowed to express distaste for government entities and suffer no consequence.
Per bounded context. Subdomain is not a notion by which to partition a system with DDD. The ubiquitous language is what you start with in your implementation. Since subdomains are notions in the problem domain, you can't really start from there. It is likely that quite often subdomains and bounded contexts will overlap, but it's not a rule.
funnily enough, these things they've been doing doesn't have to do with DDD (or does but really small part that they've touched). "No value objects cause EF doesn't support it" :) He claims that he has 10 years of experience with DDD, but doesn't know that Data model has completely nothing to do with Domain model. Just wasted 1 hour.
Bounded contexts? Determining the core domain? Ubiquitous language and consensus? Cohesiveness within bounded contexts? Of course what he's been doing has to do with DDD and Jimmy Bogard is one of the people most responsible for popularizing DDD. He was certainly my gateway to DDD, CQRS and the mediator. Maybe the data model is "just an implementation detail" but it's something that eventually needs to be done if you're ever going to actually build something and many people ask Jimmy questions about things like that all of the time. Try reading some of his blogs before calling him ignorant.
You don't understand the notion in the context of DDD. It's called ubiquitous in the sense that all stakeholders, developers and users and others alike, are able to use only that language to formulate all statements in the bounded context to which the language corresponds. So, while it is common to all involved, it is not just common, it is the only language to be used. Whenever you discover you need a new term to make a relevant statement, you extend the ubiquitous language. What this allows is avoidance of ambiguity, which is a source of costly errors in software development. Plus, if all statements and operations in the bounded context can be described in the ubiquitous language, the terms of the ubiquitous language are actually exactly what you need to implement. As soon as you have an object (in a wider, not-OOP sense, such as a function, a variable, a constant or a data structure or any other programming artifact) corresponding to each notion in the ubiquitous language, whatever a domain expert might state, using the ubiquitous language, you can easily formulate in code. This allows fast adaptation to new requirements.
@@zofe Every profession and every professional domain has its own terminology, in which terms used with one meaning in other places can have a slightly different meaning. You not knowing the terms used by DDD doesn't make them wrong. Would you expect programmers to tend to the health problems of actual bugs when debugging software?
Criticism isn't disrespectful. If every time someone criticised a persons work they just took it as disrespect all that would happen is that they would never learn from their oversights, errors and other mistakes. Receiving criticism doesn't make the critic automatically correct but it would certainly be arrogant to presume criticism amounts to disrespect, no person has God like omnipotence and infallibility.
We should all thank the State of Texas for allowing Bogard to speak so openly about the development of these projects. The developer community as a whole benefits. Bogard as always a brilliant presenter.
Great to hear specifics about actual application of DDD to real life projects. I appreciate his honesty and humility about their initial experience; such maturity is really needed as we discuss implementations of all these newer patterns and practices.
Thanks!
I'm amazed by Jimmy's honesty and openness both about the technical aspect of the project as well as about the legal system and how it works! great talk, thanks!
I don't know, it seems like there is a bit of bias in the personal annotations regarding the legal system.
Thanks Jimmy!
Mostly for being humble and admitting mistakes - really valuable for the public (and me) - and for sharing the insights in the more successful project.
I have seen a project where many new techniques such as DDD, Event Sourcing, CQRS etc. was used at the same time and not fully understood by the team, and I presume there are many of those out there - of those that survived and made it to production :).
and thanks to NDC for uploading!
I hope nobody from the judicial system in Texas saw this presentation. We'd miss you, JB ;)
"if lastName === 'Bogard' just go ahead and drop the case." brilliant.
This is a brilliant talk, but I consider that a "dad joke"
Really the illustration of this:
"If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort-but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. There’s this very long lag between what you might call the best practice in computing research over the years and what is able to leak out and be adapted in the much more expedient and deadline-conscious outside world."
This is probably the best explanation of legacy code.
funny comment
i think at the end of the day there are 2 sides - you try and encapsulate and abstractify each entities ever evolving workflow, OR you create a powerful tool that molds into different use cases and the agency/companies adapts to it. the computer itself is not engineered specifically for any business, its just made in a way where it can be flexible enough to be molded into different scenarios. so the solution is something in between those 2 paths, you want it abstract enough to have large spread but also optimized for the specific sector/industry.
Really great case study - In UK , TOGAF enterprise architecture is common , its interesting to consider how this fits with domain driver design. In TOGAF 'views' and 'viewpoints' are the perspectives (reality slices) of the differering stakeholders
Jimmy dissing the blue book just at the end :p ... fantastic presentation and... explaining the whole workshop approach in discovering and figuring out knowledge. I am interested in how many diagrams and which kinds they had to use to map this out. I like the fact he points out so much the ubi lang and contexts, not the coding aspect of the whole problematic. And also... 0 value objects haha, I love that as it proves you do not need to be evangelistic at DDD but you can still make stuff work great. Amazing presentation Jimmy, thank you.
I'm glad that he takes it so casually
An American speaker at the Norwegian Developer Conformance, in Sydney, Australia. Beautiful.
The Meaning you should seek the brand not. - Joda style ;)
Yep. What an awesome world we live in!
Good to learn about the taxas juvenile justice system
I would REALLY love to see a discussion of a system like this one, but using traits/mixins for implementing it.
This is where rubber meets the road. Just too good of an use case.
This ^
37:26 "Boss Hog sheriff or something". 🤣🤣 Maybe there was at least one other American in the room who grew up in the 80's and remembers Dukes of Hazzard.
Had to use a speaker amplifier. Wondering if NDC is taking donations for the "microphones procurement" fund.
I suspect your difficulty of using the tactical patterns comes from not having routine with them. They don't, in fact, require to be used. They provide a taxonomy of what you'll inherently create as you proceed with implementation. They are helpful with not mixing stuff. You know you need a struct. (It will be a full class in Java without JEP 169, but that doesn't make any difference.) You need to identify whether that struct is an entity or a value object, in order to know how you'll handle instantiation and mutation. Putting a label on the type when you create it helps with this. But even without the label, you should still take care of such aspects.
Great Talk
Aha So that is why a Service Oriented Architecture is preferred over monolithic for a DDD.
Not necessarily. DDD doesn't prescribe the structure of the binaries, i.e. many small executables or one large executable. In theory at least, you can put all the code of all services in a single binary too, without affecting the working of the software.
What DDD prescribes is dealing with each bounded context in isolation on the solution side. You can do this equally well with putting each bounded context into its own module in a monolith, or putting each bounded context in a separate binary executable.
The reason to go with many small binaries has more to do with operational concerns than with design/architecture. You can deploy independently (as long as you stick to well defined, agreed upon interfaces), you can test independently and perform most of the system tests at the service level, you can scale, monitor and audit each service independently. All these aspects, however, don't affect what and how each business domain concern is handled.
I'm trying to understand the need for having a monolithic Repository w/ 90 methods in the first system. Why not break it down into many more Repos?
In principle, one repo is responsible for one kind of entity. Many repos for one entity type create confusion.
But you are right, that class (well, interface) is a monstrosity. What I'd do is introduce a domain-specific language for queries at the application level. It can be graphical (a dialog with lots of checkboxes, radios, text fields, buttons and whatever, for example), but it should dynamically create queries - which you can store as such to run repeatedly - rather than hard-code a ton of different queries. Chances are that many different users will want their own handful of very specific queries, maybe even with user-specific parameters. A DSL allows them to easily define their own queries, rather than collecting and implementing the needs of many users and never satisfying all.
Amazing talk. Loved it.
17:50 just remember, everyone: the first step to good software is contempt for your end users
Was a joke my dude, we went on ride alongs to see how painful the existing system was
That wasn't the only "shot" he took at the MIBs in the video. Jimmy...you can say it's a joke but your thoughts shine through loud and clear throughout the presentation :). Just because you went on ride alongs doesn't mean you have positive overall feelings about the group you are riding with.
@@jlrosine An important part of being an American is freedom of expression. You are allowed to express distaste for government entities and suffer no consequence.
the right to express. 😊
@@seancpp At least theoretically in Texas too, right? :-D
2:35 the majestic monolith
Very good talk
Great talk.
Great presentation.
took a veeeeeery long time to go deep inside DDD ....
You thinking of Debbie, from Dallas?
bike-shaving!
Is 'ubiquitous language' per domain or per subdomain?
i think its per subdomain, since there is the example of the juvenile that is just a code for one part and a person that needs help for another
Per bounded context. Subdomain is not a notion by which to partition a system with DDD.
The ubiquitous language is what you start with in your implementation. Since subdomains are notions in the problem domain, you can't really start from there. It is likely that quite often subdomains and bounded contexts will overlap, but it's not a rule.
"microservices are the good part of DDD" what?
funnily enough, these things they've been doing doesn't have to do with DDD (or does but really small part that they've touched). "No value objects cause EF doesn't support it" :)
He claims that he has 10 years of experience with DDD, but doesn't know that Data model has completely nothing to do with Domain model.
Just wasted 1 hour.
kobac thank you for helping me save an hour of my life. (Not sarcasm!)
Bounded contexts? Determining the core domain? Ubiquitous language and consensus? Cohesiveness within bounded contexts? Of course what he's been doing has to do with DDD and Jimmy Bogard is one of the people most responsible for popularizing DDD. He was certainly my gateway to DDD, CQRS and the mediator. Maybe the data model is "just an implementation detail" but it's something that eventually needs to be done if you're ever going to actually build something and many people ask Jimmy questions about things like that all of the time. Try reading some of his blogs before calling him ignorant.
"We've done DDD with only one bounded context" how is it DDD then?
Indeed xd
?? You don't need to have multiple bounded contexts for it to be DDD.
Fort worth is more "hickster" than hipster. Dallas is more metropolitan and has the art district and pretentious people.
Really??? Perhaps you should actually visit Ft Worth and see their museums.
Honestly, i can not digest this at all, not my appetite.
The crazy parallelogram jointly thaw because possibility accordingly watch since a precious centimeter. dramatic, ubiquitous great-grandmother
A Language needs be common, rather not 'ubiquitous'.
You don't understand the notion in the context of DDD. It's called ubiquitous in the sense that all stakeholders, developers and users and others alike, are able to use only that language to formulate all statements in the bounded context to which the language corresponds. So, while it is common to all involved, it is not just common, it is the only language to be used. Whenever you discover you need a new term to make a relevant statement, you extend the ubiquitous language.
What this allows is avoidance of ambiguity, which is a source of costly errors in software development. Plus, if all statements and operations in the bounded context can be described in the ubiquitous language, the terms of the ubiquitous language are actually exactly what you need to implement. As soon as you have an object (in a wider, not-OOP sense, such as a function, a variable, a constant or a data structure or any other programming artifact) corresponding to each notion in the ubiquitous language, whatever a domain expert might state, using the ubiquitous language, you can easily formulate in code. This allows fast adaptation to new requirements.
@@a0flj0 It is still only common, because not everybody in the world is your colleague.
@@zofe That's your personal definition. Nobody else uses it, at least not in relation to DDD.
@@a0flj0 Not personal at all, it is called the English language.
@@zofe Every profession and every professional domain has its own terminology, in which terms used with one meaning in other places can have a slightly different meaning. You not knowing the terms used by DDD doesn't make them wrong. Would you expect programmers to tend to the health problems of actual bugs when debugging software?
This talk would have been better if he were able to stick to the topic of the talk and not resort into disparaging his own customers again and again.
No need to show disrespect for LEA. Just stick to your nerdy stuff.
No need to show respect for LEA, just stick to your nerdy stuff.
Criticism isn't disrespectful.
If every time someone criticised a persons work they just took it as disrespect all that would happen is that they would never learn from their oversights, errors and other mistakes.
Receiving criticism doesn't make the critic automatically correct but it would certainly be arrogant to presume criticism amounts to disrespect, no person has God like omnipotence and infallibility.
Great talk