Strategic design using ddd
âąAls KEY, PDF herunterladenâą
6 gefĂ€llt mirâą3,090 views
The document discusses strategic design using Domain-Driven Design (DDD). It notes that DDD focuses design efforts where it matters most by prioritizing the core domain and using different strategies for generic, supporting, and core subdomains. Tactical DDD patterns can be applied to the core domain. The document provides examples and poses questions to illustrate DDD concepts.
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (17)
Andere mochten auch
Andere mochten auch (20)
Ăhnlich wie Strategic design using ddd
Ăhnlich wie Strategic design using ddd (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
Strategic design using ddd
- 1. S tr at eg i c D es ig n u si n g DDD Paul Rayner @virtualgenius
- 2. 3 St a t e me n t s
- 3. A gile i s fund ame n t a l l y a v a lue-dri ve n a p p r oac h
- 4. E xc el lence i n s o f t w a r e d e s i g n is essenti al t o s u s t a i n in g c om pe ti ti ve ad van t a g e .
- 5. N ot e very p a r t of a l ar g e so f t w are sy s t e m w i l l b e w e ll d e sig ned.
- 6. 3 St o ri e s
- 7. Valerie Mar k e t i n g Dir e c tor Ultr a De a l, I n c .
- 8. Joe Di rec t o r , E -B u s in ess W rapp Pr od u c t s , In c.
- 9. Me
- 10. Co mm on t h r e a d s
- 11. Co mm on t h r e a d s S t r en g th s
- 12. Co mm on t h r e a d s C h a llen g es
- 13. A gile i s fund ame n t a l l y a v a lue-dri ve n a p p r oac h
- 14. A gile i s fund ame n t a l l y a v a lue-dri ve n a p p r oac h BUT
- 15. A gile i s fund ame n t a l l y a v a lue-dri ve n a p p r oac h BUT Softw ar e d e s i g n o n a g i l e proj ec t s o f t e n i s N O T .
- 16. E xc el lence i n s o f t w a r e d e s i g n is essenti al t o s u s t a i n in g c om pe ti ti ve ad van t a g e .
- 17. E xc el lence i n s o f t w a r e d e s i g n is essenti al t o s u s t a i n in g c om pe ti ti ve ad van t a g e . BUT
- 18. E xc el lence i n s o f t w a r e d e s i g n is essenti al t o s u s t a i n in g c om pe ti ti ve ad van t a g e . BUT O v e r - i n v es t m e n t in s o f t w a r e d es i g n i s da mag i n g t o s u st a i n e d co mp et i t i ve a dv anta g e .
- 19. N ot e very p a r t of a l ar g e so f t w are sy s t e m w i l l b e w e ll d e sig ned
- 20. N ot e very p a r t of a l ar g e so f t w are sy s t e m w i l l b e w e ll d e sig ned BUT
- 21. N ot e very p a r t of a l ar g e so f t w are sy s t e m w i l l b e w e ll d e sig ned BUT So me pa r t s , t h e p a r t s t h a t real ly m a t t e r , n e ed t o b e ver y w el l de s ig ne d
- 22. S o meth i n g is mi s s i n g
- 23. â Design is easy. All you do is stare at the screen until drops of blood form â on your forehead. â Marty Neumeier
- 27. Difficulties in software production
- 29. Difficulties inherent in the nature of software.
- 30. Change 24
- 31. Conformit 25
- 32. 26
- 33. Invisibility 26
- 34. Complexity 27
- 35. N ow w h at?
- 36. Co nnec ti n g t o P u r p ose
- 37. Market Differentiation Mission Critical The Purpose Alignment Model by Niel Nickolaisen
- 38. Market Differentiation Minimum Impact Activities Mission Critical The Purpose Alignment Model by Niel Nickolaisen
- 39. Market Differentiation Minimum Impact Parity Activities Activities Mission Critical The Purpose Alignment Model by Niel Nickolaisen
- 40. Market Differentiation Partnering Activities Minimum Impact Parity Activities Activities Mission Critical The Purpose Alignment Model by Niel Nickolaisen
- 41. Market Differentiation Partnering Differentiating Activities Activities Minimum Impact Parity Activities Activities Mission Critical The Purpose Alignment Model by Niel Nickolaisen
- 42. Market Differentiation Maintenance Not important to our strategic initiatives. Perhaps outsource? Mission Critical The Purpose Alignment Model by Niel
- 43. Market Differentiation Excel and Innovate Focus effort and resources on these processes, products and projects Mission Critical The Purpose Alignment Model by Niel
- 44. W r a p p P r o d u c ts O ur w eb si te lo gg in g fr am ew or k ki ck s bu tt .
- 45. Market Differentiation Parity Apply industry standards when possible Mission Critical The Purpose Alignment Model by Niel
- 46. Waste
- 47. Extra Features
- 48. Market Differentiation Parity Apply industry standards when possible Mission Critical The Purpose Alignment Model by Niel
- 49. Market Differentiation Partner Leverage the experience of someone who does a better job in this space Mission Critical The Purpose Alignment Model by Niel
- 50. Market Differentiation Partner Excel and Innovate Leverage the experience Focus effort and of someone who does a resources on these better job in this space processes, products and projects Maintenance Parity Not important to our Apply industry strategic initiatives. standards when Perhaps outsource? possible Mission Critical The Purpose Alignment Model by Niel
- 51. E nt er DDD...
- 52. Domain-Driven Design is not a technology or a methodology.
- 53. Itâs a set of principles and patterns for focusing design effort where it matters most.
- 54. T ac t i c al DDD Pa t t e r n s f o r m o d e l i n g , c reative c o l l a b o r a t io n a n d su p pl e s of t w a r e de s ig n
- 55. St r a tegic DDD Patter n s f o r s t r a te g i c a l l y managin g t h e m a n y m o d e l s su p por t i n g y ou r do m a in
- 56. Principle #1 Fo c us on the C or e Dom a in
- 57. G e n e r ic S u b d omain s
- 58. Su p p o r t in g S u b d om ai n s G e n e r ic S u b d omain s
- 59. Co r e D o ma in Su p p o r t in g S u b d om ai n s G e n e r ic S u b d omain s
- 60. Market Differentiation Partner Excel and Innovate Maintenance Parity Mission Critical The Purpose Alignment Model by Niel
- 61. Market Differentiation Partner Excel and Innovate Maintenance Parity Generic Subdomains Mission Critical The Purpose Alignment Model by Niel
- 62. Market Differentiation Partner Excel and Innovate Maintenance Parity Supporting Subdomains Generic Subdomains Mission Critical The Purpose Alignment Model by Niel
- 63. Market Differentiation Partner Excel and Innovate Core Domain Maintenance Parity Supporting Subdomains Generic Subdomains Mission Critical The Purpose Alignment Model by Niel
- 64. G e n e r ic S u b d omain S t r ateg ies
- 65. U s e o p en s o ur ce G e n e r ic S u b d omain S t r ateg ies
- 66. B u y it off the s h e l f U s e o p en s o ur ce G e n e r ic S u b d omain S t r ateg ies
- 67. S u p p o rting S u b dom ain S t r ateg ies
- 68. Ou t s ou r c e S u p p o rting S u b dom ain S t r ateg ies
- 69. C or e Dom ain S t r ateg ies
- 70. F o cu s o u r b e s t d es i g n e r s o n t h e Co re Doma i n C or e Dom ain S t r ateg ies
- 71. F o cu s o u r b e s t d es i g n e r s o n t h e Co re Doma i n A ppl y DD D t ac t i c a l pa tte r ns C or e Dom ain S t r ateg ies
- 72. Me Core D o mai n?
- 73. C on t e xt M ap
- 74. Anti-Corruption Layer C on t e xt M ap
- 75. Joe In t er nal S e ar ch: Core D o mai n?
- 76. W r a p p P r o d u c ts O ur in te rn al w eb si te se ar ch ki ck s bu tt .
- 77. Valerie A /B Te sti n g : Core D o mai n?
- 78. u d Partnership C on t e xt M ap
- 79. Thank You⊠paul@virtual-genius.com www.virtual-genius.com @virtualgenius
- 80. Questions
- 81. References âą Images from iStockPhoto, except: âą Boot - http://www.militarysmartbooks.org/images/600-Hot-Weather-Combat-Boot.gif âą âJoeâ - http://www.flickr.com/photos/yuri-samoilov/4105603525/ âą âValerieâ - http://www.flickr.com/photos/moglimeninolobo/1986055680/ âą Kangaroo - http://www.flickr.com/photos/tambako/5014318643/ âą The Homer - http://onscreencars.com/tv/the-homer-the-car-built-for-homer/ âą Fred Brooks - http://www-03.ibm.com/ibm/history/exhibits/builders/builders_brooksjr.html
Hinweis der Redaktion
- \n
- \n
- Working software is the primary measure of progress.\nProduct vision->sequenced product backlog->iteration planning->demo->release\n
- \n
- \n
- True stories. Names and some other details changed.\n\nLook for similarities. What similar challenges do you see in these projects?\n
- Valerie, the marketing director at UltraDeal, wants the ability to perform A/B testing for certain parts of certain pages on the company website by quarter-end, so her team can test out new marketing ideas on specified subsets of website users. Valerie knows it will drive revenue up in a big way.\n\nValerie’s been very happy with how the website content development team in IT has worked with her in the past, and she’s looking forward to what they will come up with this time. They’re a smart group of people, who really care about getting things right and understanding what she is trying to accomplish.\n\nSo far they’ve been looking at building this capability into the existing ecommerce engine. UltraDeal’s competitors are already doing this kind of thing and, based on an impressive demo of an off-the-shelf A/B testing product, Valerie would like the team to try it. \n\nThe dev lead, Gary, is concerned. He’s worried about security issues arising from hosting content on a 3rd party, and mentioned that the team has no past experience integrating with systems like this. Gary feels that the tight deadline of having it in production by quarter-end won’t leave the team time to sort out technical integration issues. Despite her good relationship with the team, she gets the feeling that they feel they could do it better themselves using the tools they already have, and that they are being railroaded into a bad design decision.\n\n
- Joe, the director of e-business at Wrapp Products, wants to get the company’s website internal search capability up to par with market standards. Currently it is too difficult for customers to find what they are looking for using the built-in search. \n\nHe’s not sure exactly how bad the situation is, but the hits for landing pages from the internal search have been trending down for months. Not only that, he’s received some emails from very frustrated customers unable to find anything useful on the site. Joe’s getting desperate. If the situation doesn’t improve soon, then they may start losing market share to competitors.\n\nNumerous meetings with IT have so far been fruitless. They want to write their own internal search framework, but Joe’s concerned about whether this is the best approach. All his competitors seem to be using off-the-shelf solutions like Solr. Not only that, IT’s track record for delivery hasn’t been the best, so why should this effort be anything different?\n\n
- Several years ago I was involved with a large effort to rewrite a legacy system. This was, as I recall, the third attempt to decommission the old system. I was the lead developer for the project, and was struggling to come to terms with how to go about such a mammoth task, and even where to start.\n\nThere seemed to be little in the way of solid industry guidance in how to approach such an accomplishment, and even fewer success stories. Our first attempt founded, and we ended the first year with little to show for our efforts other than software no one would ever likely use and unhappy stakeholders.\n\nTowards the end of that first year I read the DDD book, finding answers to many of the issues that I had been facing. Like all good agile development, we combined an iterative process approach with an incremental delivery prioritized by value, and rigorous commitment to modeling our complex business domain in the code using the tactical patterns in the book, we were able to deliver software with a rich model of the business that really met the needs of the business.\n\nAssuming we did the right thing to try rewriting the entire legacy system in one project, I still wondered how to focus the many individual design decisions every day. Where to focus our time as developers and designers? With pressure from stakeholders to demo working features early and often, it was difficult, to say the least. \n\nYet, despite our early success, I still had nagging doubts about the long-term viability and success of this approach. As far as I know, the legacy system still exists, there is another system that does something very similar to the one we developed, and they are thinking of rewriting the one we created.\n\n\n
- Ask audience what they saw...\n\n
- The team is skilled technically. \nStakeholders are on-board and engaged with the initiative.\nAgile processes, roles and practices are in place. (for the 1st two projects at least)\nThe product backlog is defined and prioritized.\n\n
- Developers are inexperienced with the business domain, and not used to working together as a collaborating team.\n(In the case of my project, we had developers - mostly new to the company, many of them contractors - distributed between 3 locations, 3 different timezones, speaking 2 different languages, and reporting up 3 different management structures).\n\nMany things being tried for the first time. Lots of technical unknowns. Heavyweight release/deployment process.\nIntegrating with a legacy system, and needing to handle large amounts of historical data.\n\n
- Here I mean the variety of design activities that developers do every day on an agile project. \nWhiteboard discussions, UML diagrams, design meetings, modeling, refactoring, TDD - these are all design activities.\nEvery one of the thousands of lines of code involved a variety of design decisions large and small, significant or not.\n\nHow do I as a developer know whether the design decision I am making right now will deliver more value to the business or less? Or maybe have no impact at all? \n
- Here I mean the variety of design activities that developers do every day on an agile project. \nWhiteboard discussions, UML diagrams, design meetings, modeling, refactoring, TDD - these are all design activities.\nEvery one of the thousands of lines of code involved a variety of design decisions large and small, significant or not.\n\nHow do I as a developer know whether the design decision I am making right now will deliver more value to the business or less? Or maybe have no impact at all? \n
- Over investment often happens when:\n- developers are focusing their finest creative energies developing an in-house logging framework for your website when there are any number of open source frameworks available.\n- your most talented developers are investing significant effort designing a solution to a mission critical issue that won’t gain you an iota of market share.\n- developers are spending hours in design meetings day after day with no code to show for it.\n- you have a team learning how to develop a native mobile solution, with no intention of making \n
- Over investment often happens when:\n- developers are focusing their finest creative energies developing an in-house logging framework for your website when there are any number of open source frameworks available.\n- your most talented developers are investing significant effort designing a solution to a mission critical issue that won’t gain you an iota of market share.\n- developers are spending hours in design meetings day after day with no code to show for it.\n- you have a team learning how to develop a native mobile solution, with no intention of making \n
- \n
- The question is, which parts really matter? Which parts do we need to put the most effort into? How do we know?\n\nRemember, we’re not talked about features here. We’re talking about the underlying design and the creation of the software structure that supports those features.\n
- Each project will be executed flawlessly from a tactical perspective. \nThe programmers and testers are skilled and dedicated. The\nProduct Backlog is well defined, prioritized by value and well managed. \nThere is a high level of collaboration between all team members involved. \nEach could have been considered a model implementation of agile.\n\nYet...\nWhy do they end up focused on the shiny technical aspects, rather than knowing where to focus their design effort to increase our competitive advantage? \nWhy are some parts of the system over-engineered, while other more strategically important areas are nearly impossible to change?\nWhy does the business feel like the development is always playing “catch-up”, rather than suggesting innovative ideas for gaining market share?\nBottom line: Why are the developers struggling to make strategic design decisions? \n\n
- This statement was made about designing everyday things.\n\nLet’s not be too hasty pointing the finger of blame at the developers...maybe there’s something else going on here...\n\nWe’re talking about SOFTWARE design here - has anything ever been said about the nature of software, and why software design is so HARD?\n\n\n\n
- We’re all familiar with the phrase, “It’s not a silver bullet.” We usually are referring to how something is good, but won’t solve all our problems.\n\nThis phrase originates from a paper called No Silver Bullet that Fred Brooks wrote in 1986. Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." He also states that "we cannot expect ever to see two-fold gains every two years" in software development, like there is in hardware development.\n\nFred Brooks argued that there is no single technology or management improvement - no silver bullet - that can ever deliver us from the werewolf...the project that is normal one moment...\n
- and a terrifying out-of-control monster the next. \n
- Aristotle distinguished between the essential and accidental (or non-essential) properties of things. Brooks borrowed that terminology for No Silver Bullet.\n\nHe said that the difficulties found in the software development process is not inherent, or essential, to software.\nWe do encounter many problems as we develop software. The process of getting people working together to build something new is incredibly hard to pull off.\nEverything in Scrum is targeted towards addressing these kinds of difficulties. The ceremonies, the artifacts, and the roles. They are all focused on addressing the human dynamic, the sociological aspect.\nBut Brooks argued, convincingly, that projects aren’t like werewolves because of these kinds of difficulties. He said this is the easy bit. These types of issues occur whenever you have people collaborating on some kind of creative endeavor. \nFor example,the book Artful Making describes how a theatre can put on a play, and the same agile principles apply. \nIterative and incremental processes are nothing new.\n\nBrooks argued the true difficulties arise because all software in its essence is fundamentally different “stuff” from other things we are trying to build.\nHe said that software has four inherent properties...properties that are essential to the very nature of software. \n
- Aristotle distinguished between the essential and accidental (or non-essential) properties of things. Brooks borrowed that terminology for No Silver Bullet.\n\nHe said that the difficulties found in the software development process is not inherent, or essential, to software.\nWe do encounter many problems as we develop software. The process of getting people working together to build something new is incredibly hard to pull off.\nEverything in Scrum is targeted towards addressing these kinds of difficulties. The ceremonies, the artifacts, and the roles. They are all focused on addressing the human dynamic, the sociological aspect.\nBut Brooks argued, convincingly, that projects aren’t like werewolves because of these kinds of difficulties. He said this is the easy bit. These types of issues occur whenever you have people collaborating on some kind of creative endeavor. \nFor example,the book Artful Making describes how a theatre can put on a play, and the same agile principles apply. \nIterative and incremental processes are nothing new.\n\nBrooks argued the true difficulties arise because all software in its essence is fundamentally different “stuff” from other things we are trying to build.\nHe said that software has four inherent properties...properties that are essential to the very nature of software. \n
- Aristotle distinguished between the essential and accidental (or non-essential) properties of things. Brooks borrowed that terminology for No Silver Bullet.\n\nHe said that the difficulties found in the software development process is not inherent, or essential, to software.\nWe do encounter many problems as we develop software. The process of getting people working together to build something new is incredibly hard to pull off.\nEverything in Scrum is targeted towards addressing these kinds of difficulties. The ceremonies, the artifacts, and the roles. They are all focused on addressing the human dynamic, the sociological aspect.\nBut Brooks argued, convincingly, that projects aren’t like werewolves because of these kinds of difficulties. He said this is the easy bit. These types of issues occur whenever you have people collaborating on some kind of creative endeavor. \nFor example,the book Artful Making describes how a theatre can put on a play, and the same agile principles apply. \nIterative and incremental processes are nothing new.\n\nBrooks argued the true difficulties arise because all software in its essence is fundamentally different “stuff” from other things we are trying to build.\nHe said that software has four inherent properties...properties that are essential to the very nature of software. \n
- At the heart of agile is a recognition that this is inherent to the nature of software. \n\nThe only software I know not needing changes is software not being used. For example, Lotus 1, 2, 3 is not being changed. No one’s used it in over a decade.\n\nAll successful software gets changed. \n\nUsers invent new ways of applying it and want it extended to do new things. Often it is changed to adapt to new business needs and processes. This property of software is the primary reason agile development is so important.\nAs the manifesto says, welcome changing requirements, even late in the process, for the customer’s competitive advantage.\n
- Secondly, software is conformit. By that we mean that we are expected to bend and reforge software to conform to the business needs. Sometimes because the software is the most recent arrival on the scene, or perhaps because it’s perceived as the easiest thing to change.\n\nWe’re not saying that all software is easy to change, or that each part of the software is equally easy to modify. But rather that this property of malleability is inherent to software. Compared the effort involved in refactoring a bridge design after the bridge has been built, to refactoring a software design. Both are difficult, but the bridge will likely require a complete rebuild.\n\nThis is the second major reason why agile is so critical for software. Agile development is iterative and incremental so that this property of software can be harnessed as business value.\n
- And thirdly, software in its essence is invisible. You can’t point to anything and say, “there’s the software.” \nIt’s like music playing. \nIt’s like the 90% of the iceberg that you know is there, hidden under the water.\nIt’s like your consciousness.\n\nAny attempt to visualize software is a poor approximation, and developers will tell you how hard it is to understand complex code or grasp a software design you are seeing for the first time.\n\n any genuine attempt to look under the wrapping shows us the difficulty of getting our minds around this complex, conformable, changing and fundamentally intangible and unvisualizable stuff we call software. \n
- Finally, software is inherently complex.  Not only technical problems, but management problems as well come from the complexity. \n\nMost medium-size software systems consist of thousands or hundreds of thousands of lines of code, with hundreds of components communicating with each other across diverse technology stacks.\n\nThe longer a system is around, the more likely it is to settle into a Big Ball of Mud, where there is no longer any coherent model or well-defined system boundaries, but rather a shanty-town of components and plethora of unintended side-effects whenever a change is made.\n\nIt makes it hard to find and control all the loose ends, and creates the tremendous understanding and communication burden we face every day.\n\nThis is what software developers are designing, and these four intrinsic properties of software are what make it so hard. \n
- We need some better ways to visualize how design fits into strategy. Let me demonstrate some tools that will help you...\n
- Align business activities and IT systems with their business purpose\n
- Mission Critical: The degree to which out activities and processes are essential to our ability to deliver our products and services and operate as an organization\nMarket Differentiating: The degree to which our activities and processes help us gain market share and enter new markets.\n
- Mission Critical: The degree to which out activities and processes are essential to our ability to deliver our products and services and operate as an organization\nMarket Differentiating: The degree to which our activities and processes help us gain market share and enter new markets.\n
- Mission Critical: The degree to which out activities and processes are essential to our ability to deliver our products and services and operate as an organization\nMarket Differentiating: The degree to which our activities and processes help us gain market share and enter new markets.\n
- Mission Critical: The degree to which out activities and processes are essential to our ability to deliver our products and services and operate as an organization\nMarket Differentiating: The degree to which our activities and processes help us gain market share and enter new markets.\n
- Minimize, as much as possible, the time, attention, talent and resources we spend on these activities. Avoid custom software at all costs, outsource the entire activity if possible.\n
- These activities create a grow market share. The goal here is to excel, be better than the competition. These activities are your company’s claim to fame.\nThis is where you want to focus your creativity. \n\nInnovation is crucial for activities, products, and processes in this quadrant to gain and maintain a sustainable competitive advantage in the marketplace.\n\nFor this quadrant, think: “If this differentiates us, then it belongs on our billboards.”\n
- Apply the billboard test. Things that fail this test are not differentiating.\n\nLook for corporate strategy documents. What are the major corporate initiatives this year? And which business capabilities need to be there to support them?\nWhat are the revenue, market share or other financial goals? \n
- Once you’ve defined the differentiating activities, almost all other activities will fall in this area.\nIf we perform poorly in this area, we harm the business and fall behind the competition.\n\nAdopt best practices. Don’t try to be different from everyone else. Remember: Most of our business activities will fall into this area.\n
- Lean - eliminate waste. Agile is very good at eliminating the waste of ...\n
- Mostly via good product backlog management, eliminating low-value features.\n\nBut there is a far more subtle and ultimately more damaging type of waste.\n\nIf we over-design, over-develop, over-allocate, over-complicate in this area, we \nOver-invest, things take longer and wind up being more difficult than they should be\nSteal from differentiating activities\nReduce our organizational agility (we have to navigate through the complexity as we attempt to respond to, or lead, market dynamics)\n\n
- Adopt best practices. Don’t try to be different from everyone else. Remember: Most of our business activities will fall into this area.\n
- Some activities are not mission critical to your organization, yet could be very significant differentiators in the marketplace.\n\neg. publisher might form partnership with an electronic content distributor\n\n37 Signals and Overcommitted. Developed iPhone app for Highrise CRM.\n
- Summarize the 4 approaches briefly.\n\nBut this is not enough. This chart is focused on business activities, how does it relate to software design?\n\nHow would this help Joe, Valerie, or me know how to focus the team in their software design process?\n
- \n
- \n
- These principles and patterns apply at two levels.\n
- Tactical, which we applied on the project I was involved with, to great success.\n\nSoftware is complex, but your business domain is likely to be far more complex, and tactical DDD can really help get that complexity under control.\n\n\n
- And strategic. There are always many models in organization, different ways of conceptualizing your business domain. \n\nFor example, Claim as benefit request vs. liability vs. line item on invoice\n\nDon’t try to make one enterprise model to serve everyone in the organization. Your business domain is not that simple.\n\n\n\n
- \n
- Generic - common to your industry\nSupporting - unique to your organization, usually in-house software grown over time, but only there to support the Core.\nCore domain is the real business asset. It’s also the smallest.\n
- Generic - common to your industry\nSupporting - unique to your organization, usually in-house software grown over time, but only there to support the Core.\nCore domain is the real business asset. It’s also the smallest.\n
- Maintenance - Use Dropbox for file sharing to someone you’ve outsourced to for maintenance.\nParity - Use PeachTree for accounting. \nCore Domain may involve enabling an integration for a partner, or creating a flexible, nice to use, common API or published language for several business partners. Such as 37 Signals and their iPhone partner.\n
- Maintenance - Use Dropbox for file sharing to someone you’ve outsourced to for maintenance.\nParity - Use PeachTree for accounting. \nCore Domain may involve enabling an integration for a partner, or creating a flexible, nice to use, common API or published language for several business partners. Such as 37 Signals and their iPhone partner.\n
- Maintenance - Use Dropbox for file sharing to someone you’ve outsourced to for maintenance.\nParity - Use PeachTree for accounting. \nCore Domain may involve enabling an integration for a partner, or creating a flexible, nice to use, common API or published language for several business partners. Such as 37 Signals and their iPhone partner.\n
- The generic subdomain must be factored apart from the domain specific parts, and decoupled from the rest of the system.\nAlso there must be a suitable off-the-shelf system. Often these conditions are not met. \nBut look twice. It may be worth a compromise on the quality or fit to get it off-the-shelf. \nOf course, integration can be expensive too, especially with poorly designed software. If you must develop the software yourself, don’t overinvest in it. Make it just good enough. And try to keep it decoupled.\nWe often underestimate the cost of in-house development, not just in money, but in terms of distraction from the core domain.\n
- The generic subdomain must be factored apart from the domain specific parts, and decoupled from the rest of the system.\nAlso there must be a suitable off-the-shelf system. Often these conditions are not met. \nBut look twice. It may be worth a compromise on the quality or fit to get it off-the-shelf. \nOf course, integration can be expensive too, especially with poorly designed software. If you must develop the software yourself, don’t overinvest in it. Make it just good enough. And try to keep it decoupled.\nWe often underestimate the cost of in-house development, not just in money, but in terms of distraction from the core domain.\n
- Outsourcing is a very popular strategy, but it often undermines DDD and Agile efforts because it greatly reduces communication between business and software people.\n\nWhen applied indiscriminately, it can do a lot of damage, but it can make sense when applied to supporting subdomains, if they are sufficiently decoupled and placed in distinct bounded contexts.\n
- Spend the effort to create a nice boundary around this context, work with business experts to develop a rich ubiquitous language and deep model of the business domain, and implement it with a supple design.\n\n
- Spend the effort to create a nice boundary around this context, work with business experts to develop a rich ubiquitous language and deep model of the business domain, and implement it with a supple design.\n\n
- Should not have tried to rewrite all of legacy system.\n\nNeeded to provide new warranty administration and associated call center functionality. Where is the Core Domain?\n\nStill not clear where we needed to innovate, but it might have looked something like this.\n\n
- These are model boundaries, different models, different languages spoken, different \n\nKeep claims administration in the legacy system. It’s a big ball of mud. No clear model boundaries, and no chance of innovating within that context. So....\n\nCarve out boundary around the area where we need to innovate, and then integrate in with legacy system. Taking care to avoid legacy system model from bleeding into the new context by using ACL. Develop call center support for administration of warranties as a partnership with the warranty administration, but keep the boundaries clean between these two contexts and integrate often. Could develop with two different teams, one per context.\n\nDo best design in the new bounded contexts, and deliver vertical slice of functionality early and often.\n\n
- These are model boundaries, different models, different languages spoken, different \n\nKeep claims administration in the legacy system. It’s a big ball of mud. No clear model boundaries, and no chance of innovating within that context. So....\n\nCarve out boundary around the area where we need to innovate, and then integrate in with legacy system. Taking care to avoid legacy system model from bleeding into the new context by using ACL. Develop call center support for administration of warranties as a partnership with the warranty administration, but keep the boundaries clean between these two contexts and integrate often. Could develop with two different teams, one per context.\n\nDo best design in the new bounded contexts, and deliver vertical slice of functionality early and often.\n\n
- Joe, the director of e-business at Wrapp Products:\n\ninternal search capability up to par with market standards.\nIf the situation doesn’t improve soon, then they may start losing market share to competitors.\nAll his competitors seem to be using off-the-shelf solutions like Solr.\n\nIT want to write their own internal search framework. What do you think? Is this core?\n\n\n
- No context map here. Let’s apply the billboard test. \n\nSo, what is it? So, would Joe’s idea to use Solr be an appropriate strategy? Yes - generic subdomain. \n\nHire a Solr expert as a contractor to implement this. This will free up other staff to focus on Core Domain areas and maybe even find new ways to use Solr to innovate,\n
- Valerie, the marketing director at UltraDeal\n\nUltraDeal’s competitors are already doing this kind of thing and Valerie knows it will drive revenue up in a big way.\nGary feels that the tight deadline of having it in production by quarter-end won’t leave the team time to sort out technical integration issues.\nIs it Core Domain?\n\nShe gets the feeling that they feel they could do it better themselves using the tools they already have, and that they are being railroaded into a bad design decision.\nWhat do you think?\n\n
- Integrated with 3rd party solution Omniture Test & Target (T&T) as a generic subdomain, minimizing modifications to the existing commerce and content management systems\n Assigned new developer to the smaller development effort associated with the 3rd party integration, with mentoring assistance from the lead developer. \nThis then allowed the lead developer (who has extensive business and front- end development knowledge) to focus more effort on the Core Domain.\nStarting to discover new innovative ways of using A/B testing to support the business, possibly in strategic ways in future. \nDelivering many more features to the business with significantly less effort, rework, risk and time than an in-house solution solution could have.\n\n
- \n
- \n
- \n