UX-driven Software Design

Course Overview
Hi everyone, my name is Dino Esposito, and welcome to my course, UX-driven Software Design. When not in training or consulting I am the CTO at Crionet, where we build products in the domain of professional sports, particularly tennis. Everyone in the software industry makes jokes about the ever-changing of requirements, constantly underestimated, well, I'm no exception, except that I don't much like these jokes and thought that there had to be a better way to approach a software development. So in this course, we are going to get the dominant evidence of what makes software development an unpredictable science, turn requirements into visual artifacts for customers, abstract visual artifacts into input and view models, and then use those models, greater than, domain, and data models, to drive design and development. This course will make you familiar with a top down methodology for building more cost effective software because you deliver the right thing right the first time. Well, sort of. The course targets primarily architects and developers, but also talks to project managers and the generic stakeholders of software projects. The course primarily compliments a modern software architecture, domain models, CQRS, and event sourcing. I hope you'll want to join me on this journey to discover a new effective way to design software with the UX-driven Software Design course, here at Pluralsight.

Acknowledgment of Requirements
Welcome back. In this module, we'll talk about requirements and how to effectively turn requirements into realistic specifications to deliver the expected experience without sacrificing functionality. As software architects and developers, we build software out of requirements. For the most part, we collect requirements through meetings, but in these meetings people usually tend to be exhaustive rather than clear about which functions and workflows are really important. At the same time, it also happens that architects tend to map on the fly every single word and verb they hear on data structures, code, frameworks, and technologies. The result is that the software built usually works, because architects are great at doing their job, but the same software fails serving the real needs of users. Extracted from the well of personal experience, let me start this module showing you an example of when software is coherent with specs, but doesn't serve the specific purpose it was designed for.

User Tasks, Screens, and Commands
Welcome back. In this module we'll talk about CQRS and the route that takes to CQRS, starting from user experience and screens and most important tasks that users have to accomplish. Changing to newer and more effective technologies and products is far more common than changing methodologies, patterns, and paradigms, but as a matter of fact, just now we are moving and we're moving from the current standard patterns and paradigms to new ones. What are we moving away from? We should seriously consider moving around from the CRUD vision of software, create, read, update, and delete entities. At the sufficiently high level of abstraction that's all of it. Any systems are to some extent CRUD systems, but taking the level of abstraction of CRUD to the utmost, leads straight to separating what alters the state of a system from what just returns one or more views of it. This is the real essence of CQRS, and this is the topic of this module.

CQRS Frequently Asked Questions
Since the days of Ancient Rome, divide et impera has been an extremely successful approach to actually getting things done. As Roman ruler Julius Caesar found out, taking enemy into dividing forces and then fighting against a smaller army made winning battles much, much easier. Similarly, the CQRS pattern is based on a very simple almost common place idea, queries and commands are very different things, and should be treated differently and separately. In complex business scenarios, a single model soon becomes unmanageable, and today most business scenarios are complex enough to make CQRS worthwhile. CQRS induces some architectural changes that can maximize the return in terms of scalability and reduced complexity, but require some investment in learning and performing a deeper preliminary analysis. The net effect is that CQRS is a pattern with many faces, even though its core idea is pretty easy to grab. The good news instead is that almost certainly, one of the many faces that CQRS has will just work for you. In this module, I collected a few common questions about the implementation of a CQRS solution and attempted to provide a comprehensive answer.