Individual consumer: Finding and purchasing a song Record labels will pull their content from the platform if it is being accessed illegally (e.g., someone in the UK listening to a track that has not yet been released in the UK).īased on the business model just outlined, and further sources of information including detailed discussions with domain experts and business stakeholders, a cross-functional team collectively agreed on the following top five use cases: They provide all of the best music that end users want to hear.Ĭustomers will otherwise use competing services where they can find music they like easier and faster.Įnforcing licensing restrictions (e.g., regional) They key details of the business model are as follows: Customer segmentĭiscover, download, and stream all of the best music in the world.īuild a media streaming and downloading service on our fully managed platform containing access to all of the best music in the world. The following examples of exploring use cases will be based on an online music platform. Review your strategy communication tools-for example a value proposition canvas-and identify the use cases that your customers care about the most. To uncover the subdomains, user journeys, and business processes in your domain, start by exploring your core use cases. You must design cross-functionally, collaboratively, and conscientiously. If high performance is your goal, you need to accept that the design of teams and the design of software systems are inextricable. You cannot achieve autonomy if managers exclusively design teams and engineers exclusively architect software systems. But creating high autonomy requires high alignment between the organization design and the software architecture. Typically, you’ll find organizations will split the responsibilities managers and coaches will take the systems approach and focus more on teams, while software engineers focus on the architecture of the software. Expert modelers combine both approaches with knowledge of the business context (presented in Chapter 2).Ĭrucially, representatives from all sides should be involved in both perspectives. And you’ll also see inside-out approaches, starting with the domain and working toward the goal. In this chapter, you’ll see outside-in approaches, starting with the goal and working in toward the domain. Multiple perspectives of the problem space are needed to create the best solution. Critically, you’ll also learn to develop a modeler’s most important characteristic: never being satisfied with the model. In this chapter, you’ll learn collaborative techniques for discovering your problem domain.

In the previous chapter you learned abstract patterns for modeling autonomy in the problem space. Udi Dahan, Service-Oriented Architecture Expert Discovering Contexts Finding service boundaries is really damn hard…there is no flowchart.

Make coffee use case diagram online