Specification Pattern vs Always-Valid Domain Model
There’s an interesting controversy between two DDD topics: the Specification pattern and the Always-Valid domain model.
Subscribe
Comments
comments powered by Disqus
comments powered by Disqus
Vladimir Khorikov
Pluralsight courses
‒ Pragmatic Unit Testing‒ Domain-Driven Design in Practice
‒ Applying Functional Principles in C#
‒ Database Delivery Best Practices
‒ Specification Pattern in C#
‒ Refactoring from Anemic Domain Model
‒ Domain-Driven Design: Working with Legacy Projects
‒ CQRS in Practice
‒ DDD and EF Core: Preserving Encapsulation
‒ Prepare for coding interviews with CodeStandard
Most Popular Articles
‒ EF Core 2.1 vs NHibernate 5.1: DDD perspective‒ C# and F# approaches to illegal states
‒ Optimistic locking and automatic retry
‒ Entity vs Value Object: the ultimate list of differences
‒ DTO vs Value Object vs POCO
‒ 3 misuses of ?. operator in C# 6
‒ Specification pattern: C# implementation
‒ Database versioning best practices
‒ Unit testing private methods
‒ Functional C#: Handling failures, input errors
‒ REST API response codes: 400 vs 500
Recent Articles
‒ Specification Pattern vs Always-Valid Domain Model‒ How to handle unique constraint violations
‒ C# 9 Records as DDD Value Objects
‒ Domain model purity and lazy loading
‒ Domain model purity and the current time
‒ Domain model purity vs. domain model completeness
‒ Is Equality Comparison a Code Pollution?
‒ How to Unit Test an Abstract Class
‒ DRY vs DAMP in Unit Tests
‒ How to Strengthen Requirements for Pre-existing Data