Andrea Saltarello and I are slated for two breakout sessions this fall at MS TechEd Europe. In addition, I’m going to run a workshop on Monday October 27. More details here.
Architecting and Implementing Domain-Driven Design Patterns with .NET
Domain-driven Design (DDD) is an approach to software design and development that focuses on the analysis of the business domain and uses ad hoc tools such as the ubiquitous language to split the business domain into distinct subdomains, each of which becomes a bounded context and requires its own architectural approach. After a brief introduction on the foundation of the DDD approach (mostly ubiquitous language and bounded contexts), we’ll focus on a reference .NET application and discuss its implementation of the Domain Model pattern (aggregates, POCO domain entities, value objects, domain services) while contrasting the use of anemic domain models. Next, we’ll compare the Domain Model implementation to the CQRS pattern. In a CQRS architecture, the business logic of the application is expressed in terms of command and events and queries take place on a physically segregated stack. Along the way, we emphasize the role and structure of the persistence layer and touch on cross-cutting concerns (scalability, caching, security) and dependency injection to protect domain logic from infrastructure technologies. Overall, this session presents the state-of-the-art for enterprise application architecture and development in .NET. By attending this session, you’ll get a global vision of the fundamental DDD patterns and see them implemented in reference application.
Applying CQRS and Event Sourcing in .NET Applications
When you use the Event Sourcing pattern in a .NET application, your data source just consists of persisted events. You don’t likely have a classic relational data store; all you store are events, and you store them sequentially as they occur in the domain. As you can guess, persisting events instead of a domain model has a significant impact on the way you organize the back end of the system. Event persistence weds well with a strategy of separating the command and query stacks (CQRS), and with the idea that distinct databases are used to save the state of the application and expose it to the presentation layer. When you add ES to a system, you just change the structure and implementation of the data source. In this talk, we just develop a mini-ERP application that works out of distinct command and query stacks and persists just events. We also discuss how to rebuild state from events and see when replaying events is an option and when you’d better use up-to-date or partial data snapshots. Overall, this session presents a concrete example of a cutting-edge application architecture that for its inherent simplicity and maintainability is gaining momentum whether you have a complex business scenario to scale out or a just a CRUD system a bit more sophisticated than plain CRUD.
See you there! And check out related book at facebook.com/naa4e. By the way, why don’t you like the page? 🙂
Two cents of software value 