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!
@finnurhrafn3 жыл бұрын
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.
@samb60307 жыл бұрын
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!
@johnking59283 жыл бұрын
I don't know, it seems like there is a bit of bias in the personal annotations regarding the legal system.
@jimifriis45076 жыл бұрын
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!
@mattbann40366 жыл бұрын
"if lastName === 'Bogard' just go ahead and drop the case." brilliant.
@billiardsforum83384 жыл бұрын
This is a brilliant talk, but I consider that a "dad joke"
@vekzdran3 жыл бұрын
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.
@bdaniel74 жыл бұрын
I hope nobody from the judicial system in Texas saw this presentation. We'd miss you, JB ;)
@danielkrajnik38173 жыл бұрын
I'm glad that he takes it so casually
@amluzia4 жыл бұрын
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
@MrKibitz7 жыл бұрын
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."
@ionezgb6 жыл бұрын
This is probably the best explanation of legacy code.
@tekal855 жыл бұрын
funny comment
@lerpmmo4 жыл бұрын
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.
@shenth275 жыл бұрын
Good to learn about the taxas juvenile justice system
@rudde72516 жыл бұрын
An American speaker at the Norwegian Developer Conformance, in Sydney, Australia. Beautiful.
@deniscloudgeek6 жыл бұрын
The Meaning you should seek the brand not. - Joda style ;)
@jameshoiby5 жыл бұрын
Yep. What an awesome world we live in!
@soapissue14 жыл бұрын
This is where rubber meets the road. Just too good of an use case.
@billiardsforum83384 жыл бұрын
This ^
@wladif7 жыл бұрын
I would REALLY love to see a discussion of a system like this one, but using traits/mixins for implementing it.
@Vlfkfnejisjejrjtjrie6 жыл бұрын
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.
@DesonteJolivet7 жыл бұрын
Great Talk
@takisbakalis3 жыл бұрын
Amazing talk. Loved it.
@ruixue69555 жыл бұрын
2:35 the majestic monolith
@ilovepickles74272 жыл бұрын
Great talk.
@roodborstkalf96647 жыл бұрын
Very good talk
@schmal9116 жыл бұрын
17:50 just remember, everyone: the first step to good software is contempt for your end users
@jiggajim5 жыл бұрын
Was a joke my dude, we went on ride alongs to see how painful the existing system was
@jlrosine5 жыл бұрын
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.
@seancpp4 жыл бұрын
@@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.
@picflight4 жыл бұрын
the right to express. 😊
@a0flj04 жыл бұрын
@@seancpp At least theoretically in Texas too, right? :-D
@chrise2023 жыл бұрын
Had to use a speaker amplifier. Wondering if NDC is taking donations for the "microphones procurement" fund.
@a0flj04 жыл бұрын
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.
@Vlfkfnejisjejrjtjrie6 жыл бұрын
Great presentation.
@tdrake594 жыл бұрын
Great talk
@califrexan7 жыл бұрын
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?
@a0flj04 жыл бұрын
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.
@__-tz6xx5 жыл бұрын
Aha So that is why a Service Oriented Architecture is preferred over monolithic for a DDD.
@a0flj04 жыл бұрын
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.
@svorskemattias4 жыл бұрын
bike-shaving!
@saaalut5 жыл бұрын
took a veeeeeery long time to go deep inside DDD ....
@danp1295 жыл бұрын
You thinking of Debbie, from Dallas?
@johnharkin22084 жыл бұрын
Is 'ubiquitous language' per domain or per subdomain?
@sirkaktor4 жыл бұрын
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
@a0flj04 жыл бұрын
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.
@morthim4 жыл бұрын
"microservices are the good part of DDD" what?
@kobac82076 жыл бұрын
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.
@rallokkcaz6 жыл бұрын
kobac thank you for helping me save an hour of my life. (Not sarcasm!)
@jameshoiby5 жыл бұрын
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.
@Seedzification6 жыл бұрын
"We've done DDD with only one bounded context" how is it DDD then?
@Suriprofz5 жыл бұрын
Indeed xd
@patbenz43274 жыл бұрын
?? You don't need to have multiple bounded contexts for it to be DDD.
@thusharajayamanna92547 ай бұрын
Honestly, i can not digest this at all, not my appetite.
@Vlfkfnejisjejrjtjrie6 жыл бұрын
Fort worth is more "hickster" than hipster. Dallas is more metropolitan and has the art district and pretentious people.
@AbNomal6216 жыл бұрын
Really??? Perhaps you should actually visit Ft Worth and see their museums.
@ciqfufajefiqke86883 жыл бұрын
The crazy parallelogram jointly thaw because possibility accordingly watch since a precious centimeter. dramatic, ubiquitous great-grandmother
@zofe4 жыл бұрын
A Language needs be common, rather not 'ubiquitous'.
@a0flj04 жыл бұрын
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.
@zofe4 жыл бұрын
@@a0flj0 It is still only common, because not everybody in the world is your colleague.
@a0flj04 жыл бұрын
@@zofe That's your personal definition. Nobody else uses it, at least not in relation to DDD.
@zofe4 жыл бұрын
@@a0flj0 Not personal at all, it is called the English language.
@a0flj04 жыл бұрын
@@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?
@zurvey4 жыл бұрын
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.
@demisx4 жыл бұрын
No need to show disrespect for LEA. Just stick to your nerdy stuff.
@big-mezza-biz4 жыл бұрын
No need to show respect for LEA, just stick to your nerdy stuff.
@XibaXela3 жыл бұрын
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.