Tag DRY

DRY revisited

Another principle we should follow when building a software project is the DRY principle. The abbreviation stands for Don’t Repeat Yourself. While it seems pretty straightforward and intuitive, this principle is more than meets the eye. Let’s see how it is so.
Vladimir Khorikov
Vladimir Khorikov
Twitter Email LinkedIn
My book
Unit testing book
Click here to get a 40% discount
Pluralsight courses
Pluralsight ‒ 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
‒ Validation and DDD
‒ Encapsulating EF Core Usage
‒ Prepare for coding interviews with CodeStandard
citadel Citadel Password Manager Privacy first. No data collected, period.
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
MSMVP
Recent Articles
‒ Storing information in its highest form
‒ Which collection interface to use?
‒ Generic types are for arguments, specific types are for return values
‒ Modeling Relationships in a DDD Way
‒ Encapsulating EF Core Usage: New Pluralsight course
‒ Collections and Primitive Obsession
‒ How to Assert Database State?
‒ Should you Abstract the Database?
‒ Database and Always-Valid Domain Model
‒ Specification Pattern vs Always-Valid Domain Model
» All articles