- 2003 - Eric Evans - Domain-Driven Design - Tackling Complexity in the Heart of Software, gdrds, 1drv
- 2013.VaughnVernon.Implementing Domain-Driven Design, amazon, 1DRV
- 2015.1ed.Millett.Tune.Patterns, Principles and Practices of Domain-Driven Design 1drv
- 2016.VaughnVernon.DomainDrivenDesignDistilled, 1drv
- Strengthening your domain
series by Jimmy Bogards
- TechEd Europe 2014: Architecting and Implementing Domain-Driven Design Patterns with Microsoft .NET
- VaughnVernon/IDDD_Samples_NET
- naa4e SDD
- Master's thesis, CS Department, University of Copenhagen, spring 2009, Domain-driven design in action: Designing an identity provider
- DDD insights blog
- Colorado slides
- IDDD excerpt
- IDDD excerpt 2
- Tackling Business Complexity in a Microservice with DDD and CQRS Patterns msdn
- eShopOnContainers sample
Ordering API - jbogard/MediatR Simple, unambitious mediator implementation in .NET
- A .NET implementation of Domain Driven Design (DDD) sample application based on Eric Evans' examples included in his great book.
- ndddsample on google code
- model a single sub-domain at a time, focus on autonomous pieces of the domain, resulting software is closer to business understanding, often no side effects
- It describes independent problem areas as Bounded Contexts (each Bounded Context correlates to a microservice)
- avoid chatty communications between microservices
- you should create a boundary around things that need cohesion. It is similar to the Inappropriate Intimacy code smell when implementing classes. If two microservices need to collaborate a lot with each other, they should probably be the same microservice.
- Persistence Ignorance (PI): classes modeling the business domain should not be impacted by how they might be persisted. Thus, their design should reflect as closely as possible the ideal design needed to solve the business problem at hand, and should not be tainted by concerns related to how the objects’ state is saved and later retrieved. Some common violations include domain objects that must inherit from a particular base class, or which must expose certain properties. Sometimes, the persistence knowledge takes the form of attributes that must be applied to the class, or support for only certain types of collections or property visibility levels. There are degrees of persistence ignorance, with the highest degree being described as Plain Old CLR Objects (POCOs) in .NET, and Plain Old Java Objects (POJOs) in the Java world.