The patterns of distributed systems help us to build maintainable, reliable, and scalable enterprise solutions. In this course, you will see how the theory of the CAP Theorem applies to the practice of using an Enterprise Service Bus. You will see how Domain Driven Design breaks down a problem, and how Event Sourcing helps implement and integrate those pieces.
Mathematician and software developer, Michael L Perry applies formal proof to creating reliable software. He has developed a method starting from the works of the greats (Meyer, Rumbaugh, Knuth), and embodied it in his open-source frameworks (Update Controls and Correspondence).
Domain Driven Design Hello. Welcome back to Module 2 of Patterns for Building Distributed Systems for the Enterprise. In this module we're going to be talking about Domain Driven Design. This was a book written by Eric Evans back in 2006. It's all about methods for working with business owners in order to build custom software. The premise of this book is that we should let the problem domain drive the software design and not try to make the problem conform to the capabilities of the software. Too often we approach a problem by modeling it as rows and columns in a database and then writing CRUD operations to manage that data. When we deliver such applications to the business owners, they can often find no relationship between the data grids and input forms that we've delivered and the actual business processes and workflows that they were trying to model. Evan's method seeks to change all that. We don't have time in this course to approach a complete review of this book, but for a deeper dive into domain modeling check out Steve Smith's course on Creating N-Tier Applications in C#. Also, check your Pluralsight feed for a future course on DDD, but in this course we're going to focus on just three core concepts presented in the book. They are the Ubiquitous Language, Bounded Contexts, and Aggregate Roots. As you do further research in the patterns covered in this course, these concepts are going to come up time and time again, and a basic understanding of these concepts will help you in this research.
CQRS Welcome back. This is Module 3 of Patterns for Building Distributed Systems for the Enterprise. In this module we're going to be exploring CQRS. CQRS is simply a pattern. Despite what some have said, CQRS is not an architecture, it's not an architectural style, and it's not a principle. It's just a pattern. CQRS stands for Command Query Responsibility Segregation. It was named by Udi Dahan and Greg Young. The pattern is based on a guiding principle called Command Query Separation, but the pattern is applicable to very specific circumstances. In this module we'll examine the broader principle of Command Query Separation, and then we'll discuss the specific situation to which the pattern of Command Query Responsibility applies. With that criteria in mind, we'll examine the PharmaNet application to see if we can find an example of that particular situation. And then finally we will rewrite the code in that one particular module to see how it improves.
Append Only Models Welcome back to Patterns for Building Distributed Systems for the Enterprise. In this module we're going to be studying Append-Only Models. These tools have evolved specifically to solve the problems that arise with distributed systems. What's unique about an append-only model is that you can never update or delete the data. You can only insert. You just need to append new data to the end. This gives us some advantages. Updating replaces existing information. Deleting purges it. But because you can do neither in an append- only model, you cannot destroy information. This makes for a very accurate audit log, and it also makes it very useful for integration as we'll soon see. These kinds of models collect an entire history of information, so you can go back through the history to correct any errors that might have occurred. When using an append-only model with the CQRS pattern, your commands will append new information to the model, and your queries will replay the history in order to answer a question. We'll be talking about three different types of append-only model: Event sourcing, event streaming, and historical modeling.
Operational Concerns Since you are watching this course, you are probably not the person that gets woken up at midnight when there's a problem at the data center. That'll be your operations team and your network team and possibly configuration management. These people are your best friends, and this module is about making them happy. In this module we're going to be talking about all of the operational concerns of building an application using CQRS and these related patterns and tools. In this module we'll talk about configuration of distributed systems, and we'll see some patterns that'll make the jobs of the operations and network teams that much simpler with regard to configuration. And then we're going to talk about versioning of a distributed system especially as it relates to database versioning, service versioning, and message versioning. And then finally we're going to talk about deployment of distributed components, and we'll look at things you can do to make deployment of your application quick and easy.