An Introduction to Domain Driven Design for Product Managers

3,616 views

Published on

A presentation to the BBC Product Management community, introducing the concepts, processes and techniques of Domain Driven Design, including Domain Modelling and URL design. Also talks briefly about the Semantic W

Published in: Technology, Business
1 Comment
9 Likes
Statistics
Notes
No Downloads
Views
Total views
3,616
On SlideShare
0
From Embeds
0
Number of Embeds
53
Actions
Shares
0
Downloads
73
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide
  • Hello - I’m here to talk about Domain Driven Design (and the Semantic Web) at the BBC.\n\n“Common Sense, made complicated.” not really. It’s easy.\n
  • - There were* approx. 320 manually managed indexes\n on the BBC Sport site\n - 150 or so in football, 22 rugby clubs, 30 cricket teams\n \n - But we are missing some important ones:\n - No competition pages (e.g. Premier League, Champions League)\n - FC Barcelona\n - Real Madrid C.F.\n - F1 teams and drivers\n \n - All would have value from an audience & business perspective.\n \n \n *= we have recently launched dynamically-aggregated football team pages\n\nI was responsible for design\nFrustrated at limitations of system\n\n\nCurrently there are too many pages to manage manually for a small editorial team 7 days a week\nWe need to drastically reduce the number of pages that are manually managed - by approximately 300\n\nThere are approx 320 manually managed ‘indexes’ - 150 or so in football, rugby teams, cricket teams and further ambitions around F1\nDifficult to integrate statistical information with editorial\nwhich is why the metadata and tagging projects are an integral part of long term strategy\n\n
  • The first step is to relax. Forget about the product. Forget about the website.\n\nIn a nutshell, DDD is about designing around the subject area of interest to your defined user group.\n\nAnd that’s pretty much it.\n\nWhat I’m going to talk about:\n\n- The DDD process and why it’s a good thing.\n- A couple of techniques - Domain Modelling and URL design\n- How this fits into the “One BBC, four devices” strategy\n- How this fits in to the wider Web\n\n\n
  • OK, so the process. It’s all about understanding how your users (and indeed, you and your development team) think about the domain.\n\nDDD involves users from the beginning and every stage throughout the process - talk to users about the domain, make notes on the words they use and use those words all the way up the stack.\n
  • The idea here is that by taking note of how your users refer to things, the whole development team can use the same language - al the way up and down the development stack - from database to CSS mark-up.\n\nA shared language = better communication = a better product.\n
  • Never stop trying to understand the domain. James - sports competitions with defined structure vs editorial defined things e.g. Premier League, Wildlife Finder (Linnaenan Taxonomy) etc vs ‘Libya in Crisis’\n\nYou’re probably not going to get it right first time. Don’t worry. Keep talking to users, keep sketching - refine your understanding.\n
  • Another important thing here is the balance between experts and casual users - the experts probably have a very detailed understanding of the domain - which is great, but it might not be what you want to present to the majority of the audience.\n\nGet the model right, and precise, behind the scenes, and then simplify as you go up the stack. This allows you to introduce new features easily, without huge development cost.\n\nIf you model it now, then that gives you hooks to build new functionality later - if you leave it out now, you’re accruing technical debt..\n
  • Forget, for a short while, that you’re building a website. Just have a chat. Get involved. Understand the subject.\n\nNote down the concepts, the nouns, the things they talk about. Those will be your primary domain objects.\n\nYou’ll probably want to bear in mind some kind of scope, of course - so work out what the most important things are.\n
  • After capturing the things, talk to your users about how those things are related - the verbs.\n\nThis will be important later, because it’s how we can make the product linked up in a coherent, natural way - one which fits how we make sense of the world.\n
  • \n
  • \n\n
  • The easy bit, your nouns. The things people will want to talk about, will search for, will link to.\n
  • \n
  • One and only one = MUST\n\nZero and One/Many = CAN\n
  • \n
  • One to One = Is it the same thing?\n\nOne to Many = the most common - sometimes you might want to elaborate with ‘one and only one’, ‘zero or one’ etc.\n\nMany to Many = Suggests there’s something in the middle missing - but not always - all depends on what you’re trying to communicate.\n
  • \n
  • This can be a bit tricky - it takes a while to get used to it, but it’s just practise:\n\nA Stadium will host one or many Matches,\nA Match will take place at one and only one Stadium.\n\nThing, verb next to it, end of the line, other thing.\n
  • The domain model is where you get everyone involved - a shared understanding of the model helps everyone work together to give the users want they want & need. \n
  • Because it’s how Google works. If you care about SEO, if you care about your audience finding stuff, you should care about URL design.\nAlso, the Web has the potential to be the platform that supports all the other platforms - the 4 screens that Ralph talks about...they can all talk to, and fetch things from, the Web. Build it once, have it everywhere..\n
  • What is persistent? This means that your URL for any given resource should be the same today, tomorrow, and in 5 years time. Why? If you start changing your URLs I won’t be able to find that page I really liked tomorrow, and my link to you that I’ve published on my site won’t work.\n\nWe need persistency, or our experience is broken. Readable is a delight – I like being able to read URLs. I don’t know what “all that rubbish” at the end of a URL is. Hackable improves my user experience.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • We’re not alone - link to external stuff as well (which is a BBC Trust requirement..)\n\nMusic editors contribute to Wikipedia, which is then brought in to BBC, also benefits wider web.\nSimilar with Wildlife Finder, and with Olympics & world cup, we’ve added our knowledge of stadia etc. which then everyone can use as a ‘public service’.\n
  • \n
  • \n
  • \n
  • Multi-platform:\n\nMake it easier to deliver 10 products to 4 screens\n\nAs content from different products is stored in the Content Store, we will increasingly be able to deliver richer experiences to mobile, IPTV and tablet devices, as well as desktop.\n
  • Contextual (or horizontal) navigation around BBC content would also be made easier.\n\nAt the moment the existing static infrastructure makes it very difficult to link to other relevant content within the BBC.\n\nUsing a dynamic infrastructure will make it easier for us to link to other relevant products.\n
  • Technology and publishing systems\n\nBegin working with the Newsgathering and other TV production teams to work out and define how we can keep data more consistent from programme creation to broadcast/web/mobile.\n
  • External Suppliers\n\nStart discussions with external suppliers to use linked data and content identifiers to minimise distribution and processing costs of feeds and data.\n
  • \n
  • An Introduction to Domain Driven Design for Product Managers

    1. 1. DOMAIN DRIVEN DESIGN AND THE SEMANTIC WEB AT THE BBCDATE SPEAKERS 14/10/2011 PAUL RISSEN, JAMES HOWARD, SILVER OLIVER
    2. 2. THE GOOD OLD DAYS?TOO MANY MANUALLY MANAGED PAGES
    3. 3. CLEAR YOUR MINDWHAT IS DOMAIN DRIVEN DESIGN, ANYWAY?
    4. 4. GET INSIDE THE HEADS OF YOUR USERSUSER RESEARCH - TALK AND SKETCH OUT HOW THEY SEE THE WORLD
    5. 5. USE THEIR LANGUAGEWELL, PERHAPS NOT ALL THEIR LANGUAGE...
    6. 6. ASK QUESTIONSNEVER STOP TRYING TO UNDERSTAND THE DOMAIN
    7. 7. GET THE BALANCE RIGHTCOMPLEXITY BEHIND THE SCENES, SIMPLICITY UP FRONT
    8. 8. THINGS, NOT PAGESPEOPLE DON’T CARE ABOUT THE DOCUMENTS
    9. 9. IT’S THE LINKS THAT MATTER“EVERYTHING IS DEEPLY INTERTWINGLED” - TED NELSON
    10. 10. AN EXAMPLE - THE FOOTBALL DOMAIN
    11. 11. COMPETITION GROUP STADIUM MATCH TEAM PLAYERAN EXAMPLE - THE FOOTBALL DOMAIN
    12. 12. THE THINGSTHE DOMAIN OBJECTS
    13. 13. END OF THE LINESSOMETHING, NOTHING, OR LOTS OF THINGS
    14. 14. END OF THE LINESSOMETHING, NOTHING, OR LOTS OF THINGS
    15. 15. END OF THE LINESSOMETHING, NOTHING, OR LOTS OF THINGS
    16. 16. CONNECTING COMBINATIONSTHE MOST COMMON ONES
    17. 17. THE CONNECTIONS...BUT HOW ARE THEY CONNECTED?
    18. 18. READING THE RUNESSUBJECT, PREDICATE, OBJECT
    19. 19. THE FIRST MODELCOMMUNICATION IS THE KEY
    20. 20. URL DESIGNWHY YOU SHOULD CARE ABOUT URLS
    21. 21. URL DESIGNIT’S WHAT THE WEB WAS MADE FOR
    22. 22. A PAGE FOR EVERY TEAM...AND A PAGE AGGREGATING ALL TEAMS
    23. 23. A PAGE FOR EVERY PLAYER
    24. 24. A LIST OF PLAYERS FOR A TEAM
    25. 25. A PAGE PER THING...AND AGGREGATIONS, TOO
    26. 26. WHICH WIRE SHOULD YOU CUT?COOL URIS DON’T CHANGE - DESIGNING FOR THE LONG TERM
    27. 27. THIS ONE?HTTP://WWW.BBC.CO.UK/PROGRAMMES/B006TS0G
    28. 28. THIS ONE?HTTP://WWW.BBC.CO.UK/PROGRAMMES/B00X338L
    29. 29. THIS ONE!HTTP://WWW.BBC.CO.UK/PROGRAMMES/B00JNWLC
    30. 30. URL DESIGNIT’S WHAT THE WEB WAS MADE FOR
    31. 31. THE SEMANTIC WEBIT’S NOT THE DOCUMENTS THAT MATTER, IT’S THE THINGS THEY ARE ABOUT
    32. 32. THE SEMANTIC WEBSTITCHING INTO THE FABRIC OF THE WEB
    33. 33. - INVESTIGATE AND UNDERSTAND THE DOMAIN OF YOUR PRODUCT- A COMMON LANGUAGE BETWEEN USERS, DEVELOPERS, DESIGNERS, PRODUCT MANAGERS- A DOMAIN MODEL SHOWS YOU THE MOST IMPORTANT THINGS, AND HOW THEY’RE CONNECTED- EVERYTHING SHOULD FLOW FROM THE MODEL - DATASTORE, DESIGNS, URL SCHEMAS- ONE URL PER THING - MUST BE PERMANENT, NICE IF IT’S READABLE & HACKABLE- SEARCH ENGINES ARE YOUR LEAST ABLE USER - DESIGN FOR THEM & ACCESSIBILITY WILL RESULT- DESIGN FOR THE WEB FIRST, THEN MAKE APPROPRIATE REPRESENTATIONS FOR EACH PLATFORMIN SUMMARY, THEN...
    34. 34. “HOW WE MAKE WEBSITES”HTTP://WWW.BBC.CO.UK/BLOGS/RADIOLABS/2009/01/HOW_WE_MAKE_WEBSITES.SHTML“DESIGNING FOR YOUR LEAST ABLE USER”HTTP://WWW.BBC.CO.UK/BLOGS/RADIOLABS/2009/03/DESIGNING_FOR_YOUR_LEAST_ABLE.SHTMLIF YOU READ TWO THINGS AFTER THIS PRESENTATION, MAKE IT...
    35. 35. WHY SHOULD WE CARE ABOUT THIS?WHAT WE’RE DOING NOW...
    36. 36. FOUR SCREENS, TEN PRODUCTSTHE FUTURE OF MULTIPLATFORM
    37. 37. CONTEXTUAL NAVIGATIONNATURAL, RELEVANT WAYS AROUND OUR CONTENT
    38. 38. BETTER WAYS OF WORKINGWORKING ACROSS TEAMS & PLATFORMS
    39. 39. THE WIDER WEBPURVEYORS OF FINE INFORMATION
    40. 40. THANK YOUANY QUESTIONS?

    ×