[2024]Digital Global Overview Report 2024 Meltwater.pdf
Domain Driven Design - DDDSydney 2011
1. Guerrilla Domain Driven Design All the really important stuff you need to know about Domain Driven Design Jak Charlton www.thinkddd.com Google+ : jakcharlton@gmail.com Twitter : @jakcharlton
DDD is a way of thinking, a set of priorities.DDD is a methodology for evolving software that closely matches our business domainsAlthough the book includes a fair bit of code, and a fair number of software patterns these are the least important bitIt is about thinking differentlyIt is about changing our priorities from the technical problem, to the business problemSoftware projects rarely fail due to technical constraints or decisions – they usually fail due to not understanding the problem
DDD is a way of thinking, a set of priorities.DDD is a methodology for evolving software that closely matches our business domainsAlthough the book includes a fair bit of code, and a fair number of software patterns these are the least important bitIt is about thinking differentlyIt is about changing our priorities from the technical problem, to the business problemSoftware projects rarely fail due to technical constraints or decisions – they usually fail due to not understanding the problem
DDD is a way of thinking, a set of priorities.DDD is a methodology for evolving software that closely matches our business domainsAlthough the book includes a fair bit of code, and a fair number of software patterns these are the least important bitIt is about thinking differentlyIt is about changing our priorities from the technical problem, to the business problemSoftware projects rarely fail due to technical constraints or decisions – they usually fail due to not understanding the problem
This term has become widely abused and bastardisedIn DDD, a Domain is a “Sphere of Knowledge, Activity or Influence”In Amazon terms, Ordering is a Domain, Fulfillment is a Domain, Shipping is a Domain, Accounts is a DomainA Domain represents a tightly related area of business activity
Too often we lose track of this fundamental conceptThe Domain represents an area of activity in our businessesSo that’s where our software project should be focusedWe get distracted by too many other things – we need to keep pulling back to the domain and the knowledge around the domain
Software is a wicked problem.Until you actually finish a piece of software it is impossible to estimate how long it will take to completeOr put another way, it takes just as long to accurately estimate as it does to complete it(which never stopped project managers wanting an estimate)But, as we progress, we learn moreEstimates get more accurateWe understand the problem betterWe get closer to a solution
Life is a journey, the destination sucks – but if you stop and look around once in a while, you might at least enjoy the ride.Software is an exploration into the unknown.Sure sometimes you have CRUD App 0003 to write – and you know pretty much what you’re gonna do – in that case don’t use DDDBut if you have a real business problem to solve, then it’s unlikely you know the way to get to the finished product yetAnd you probably don’t even know what the finished profuct looks likeScrum is keen on the concept of “Definition of Done” – well the bad news for scrum is, there really isn’t one – there are shades of DoneYou’ll know when you get there- till then enjoy the journey
Whether you follow Agile, Scrum or Waterfall – Development is an iterative craftPerformance, Feedback, RevisionDo something, validate it, revise it – repeat
Software is a team sportNot only a development team – but a domain driven teamA team that includes the domain experts, the users, the BAs and managers, the CTOIf you don’t play as a team, then you can certainly expect to fail as one
Not just users, not BAs – Domain Experts really know
It is essential in softwaredevelopemnt that you maintain a close relationship between the people developing the software and the expertsDomain experts have a deep understanding of the businessDevelopers have a deep understanding of computersThese are the people who must work closely together
Brainstorm and experimentDDD really promotes visibility – speak to people, use whiteboards, use cards, post it notes, blu tack and big marker pensDraw things out, throw ideas around. Talk about terms that don’t make sense, or you don’t understand.Explain things that others don’t understandIf you can’t explain something properly, you don’t understand it either.
The model is the latest version of all the knowledge the team has gathered about the problemIt is the essence of everything you know at any point in timeIt is probably never done, just like the Sistine chapel, but it should always be getting closer to the problem
A deep model provides a lucid expression of the primary concernsof the domain experts and their most relevant knowledge while itsloughs off the superficial aspects of the domain
The model is the foundation of DDDThe model is the representation of the working parts in your business processAnd the model forms the backbone of the language the team uses to communicate
One language to rule them all, one language to bind them
In DDD it is important that your code is a strong representation of your domainIf your code does not closely reflect your business domain, then you are dealing in abstractions.A primary purpose of DDD is to remove abstractions
Keep refining your models – refactoring can take place away from the code as well as in the codeAs you refactor you will discover new places where the model needs refinement or deeper exploration
A supple design is easier to change and adaptMake it flexible enough to change, but rigid enough to maintain integrityAvoid rigidityLoosely coupled, highly cohesive
