Is Entity the same as Value Object?
Check out my latest article: Is an Entity the same as a Value Object? It’s an answer to a quite deep question a fellow reader asked me a couple months ago. This question prompted me to ponder for quite awhile, which rarely happens when such basic topics as entities and value objects are involved. So, I hope you’ll enjoy this question too. P.S — This is probably the last article I’m writing about Domain-Driven Design on my blog, as I plan to switch gears towards unit testing.
People behavior and unit testing
I have another metaphor for you. This time, it’s the comparison of people behavior and unit testing. In the book, I talk a lot about the necessity to focus your unit tests on the system’s observable behavior and disregard implementation details. Doing so increases the tests' accuracy in pointing out errors in code. This is one of the primary drivers of value in unit testing: you want your tests to turn red only when the application’s behavior no longer matches the customer’s expectations, not when you change implementation details.
DDD and bulk operations, part 2
Here’s the second (final) part of the article about combining DDD with bulk operations: https://enterprisecraftsmanship.com/posts/ddd-bulk-operations#command Note that I’ve posted it to the same page as part 1, the link above is an anchor to the newly added sections.
DDD and bulk operations
Domain-Driven Design in combination with bulk operations is a topic I wanted to write about for a long time. Recently, I received a question about how to combine the two, which prompted me to finally write this article. Here it is: DDD and bulk operations. The article turned out quite lengthy, so I’m splitting it in two. This is part 1; part 2 will be available next week. I also want to try something different here: I’ll post part 2 not as a separate article, but continue writing to the same page.
Advanced error handling techniques, part 2
Check out part 2 of the Advanced error handling techniques series. This post shows how to combine ASP.NET validation attributes with DDD Value Objects for input validation such that you have the best of the two worlds: Enjoy the declarativeness of ASP.NET validation attributes Keep the domain knowledge DRY and concentrated in the domain layer Simplify the controllers In the next article, I’ll try to lay out a solution for gathering and returning to the client multiple errors.
Fail fast principle and human behavior
I remember an unpleasant situation I witnessed a few years back at my day job. There was a technical lead on a project adjacent to mine and for one reason or another, his project manager decided to give his role (the tech lead role) to another team member. The manager discussed this decision with the tech lead first, the lead seemingly had no objections, and so the manager announced the decision to everyone.
The Unit Testing book is sent to production!
My Unit Testing: Principles, Patterns and Practices book has reached the final stage: it has just been sent to production, which means it will go to print in about two months. Manning has a multi-step review process, where they ask people from the industry (not Manning employees) to review the book at different stages of development. I just received the results of the final review. I expected that people would like the book but I didn’t anticipate so overwhelmingly positive feedback.
Advanced error handling techniques, part 1
I sometimes receive similar questions from different people, which is always a sign that the topic in question is interesting and worth writing about. But I have never received the same question from three (3!) people within the span of one or two weeks. Here’s this question: How can I go about responding with different HTTP status codes depending on the nature of the failure without API (UI) logic leaking into the domain layer?
How to name a test that checks for ArgumentNullException?
Some time ago, I wrote an article about naming unit tests. The main takeaways from that article are: Don’t use a rigid test naming policy. Name the tests as if you were describing the scenario in it to a non-programmer who is familiar with the problem domain. To illustrate these points, I used an example of transforming a test name from this:
You are naming your tests wrong!
Check out this blog post I wrote about how to name a unit test. Main points: Don’t use a rigid test naming policy. Name the tests as if you were describing the scenario in it to a non-programmer familiar with the problem domain. Separate words in the test name by underscores. Don’t include the name of the method under test in the test name.