• Value Objects explained - I’ve already written about base entity class. Today, I’d like to continue with Value Object base class I use in my projects. Also, I’ll share some best practices regarding Value Objects implementation. Value Objects: what is it? An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object. Value Objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are. [Enterprise Craftsmanship]
• Economy of Tests - Joint post with Konstantin Kudryashov. A common complaint with teams that first try their hand at automated testing, is that it is hard, costly, and not worth the effort. On the other hand, supporters say that it saves them time. In this post, we’ll try to add some nuance to the discussion. We’ll take a look at how different levels of automated testing affect the cost of development, both in the short and the long term, for both greenfield and brownfield projects. Finally, we’ll look at a simple strategy for introducing tests and migrating them across test levels, in order to reduce maintenance costs. [Mathias Verraes]

Permalink | From 29 December 2014 to 04 January 2015 | Last updated on: Mon, 7 Jun 2021 09:18:52 GMT

• Don't use Ids in your domain entities! - How often do you see code like this in your domain model? public void Ship(int orderId, int customerId, string address) { Shipment shipment = _existingShipments.Single(x => x.OrderId == orderId); if (shipment.CustomerId == customerId) { // Do something } } Seems pretty good, doesn’t it? Well, it doesn’t. I’ve already pointed using Ids in domain entities as a bad practice, but I see developers - even sophisticated ones - write such code over and over again, so this topic definitely deserves a separate article. [Enterprise Craftsmanship]
• How Much Testing is Too Much? - Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles – as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn’t tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric. [Mathias Verraes]

Permalink | From 22 December 2014 to 28 December 2014 | Last updated on: Mon, 7 Jun 2021 09:18:52 GMT

• Async/await in C#: pitfalls - I’d like to discuss some common pitfalls of async/await feature in C# and provide you with workarounds for them. [Enterprise Craftsmanship]

Permalink | From 15 December 2014 to 21 December 2014 | Last updated on: Mon, 7 Jun 2021 09:11:15 GMT

• I/O Threads Explained - Microsoft has released async/await feature in .Net 4.5. It’s a really great stuff as it significantly simplifies one of the most painful areas - asynchronous programming. Before that, Task Parallel Library (TPL) and Parallel LINQ (PLINQ) were released in .Net 4.0. They address problems with parallel programming - another painful area in .Net. I often see programmers struggling with a question when to use each of these features. Let’s step back and recall what does it actually mean to be asynchronous or parallel. [Enterprise Craftsmanship]
• Let It Crash - “Programming Erlang: Software for a Concurrent World, 2nd ed” by Joe Armstrong, is not just a great introduction to the language, but also offers a glimpse into the “Let It Crash” philosophy that drives it. It’s a great read, even if you have no intention of programming in Erlang. I’ve selected and reordered a number of passages that were scattered across the book, and added some comments, that I hope will do the book justice. The Erlang view of the world is that everything is a process and that processes can interact only by exchanging messages. Having such a view of the world imposes conceptual integrity on our designs, making them easier to understand. The real world actually has independent things communicating through messages. [Mathias Verraes]

Permalink | From 08 December 2014 to 14 December 2014 | Last updated on: Mon, 7 Jun 2021 09:18:52 GMT

• Separation of Concerns in ORM - Last week we compared Entity Framework and NHibernate from a DDD perspective. Today, I’d like to dive deeper into what Separation of Concerns (SoC) is and why it is so important. We’ll look at some code examples and features that break the boundaries between the domain and persistence logic. Separation of concerns in ORM There are several concerns we deal with in software development. In most applications, there are at least three of them clearly defined: UI, business logic and database. [Enterprise Craftsmanship]

Permalink | From 01 December 2014 to 07 December 2014 | Last updated on: Mon, 7 Jun 2021 09:11:15 GMT