Lawrence Okoth-Odida

Herberto Graça recently wrote a great summary on Value Objects , and I commented on it on Reddit , saying: ...something that could flesh out the case for value objects [is] the fact that it allows you to model complex rule interactions by representing the concepts of the core domain and letting them interact as they would in said setting . This results in code that reads very much like "business-speak", making it easier to translate back and forth from the stakeholders to the developers. The comment has its own illustration of the idea, but I wanted to expand on the utility of value objects in a bit more depth in this blog post. If you need a primer on what value objects are in the first place, Graça's article is a great start. A lightning-fast DDD reminder Within Domain Driven Design , we separate our code into at least two distinct models: The Application Model , which crystalises the top-level use-cases (or commands ) of the system (e.g. ApplyForFinancialLoa...

Persisting application state is not an easy job , to say the very least. We have an entire cottage industry of vendors who promise to simplify these issues for us. But there is a long-existing design pattern that which provides a logical separation in your application to help tackle this problem, without needing to commit to a specific database technology or library. The repository pattern aims to isolate the complexities concerning the persistence of data (complexities which are often vendor specific) from the the business-logic of your application. In your app, you will usually: 🔍 Find some specific entity in question 🛠️ Perform some operation on that entity, obeying a set of rules to ensure that it doesn't enter an invalid state 💾 Persist that entity Steps (1) and (3) both concern communication with the storage layer (e.g. the database) that you are using. It will involve mapping the data to/from storage and into objects/data structures that your app understa...

So you need to do some time-specific calculations in your application. It’s related to the current time, so you do the usual thing, and new up a DateTime object: $now = new DateTime() ; Seems innocuous, right? But you quickly run into some pretty nasty problems: Your code is now very difficult to test reliably . To make any assertions on the behaviour that aren't time-flakey (i.e. they work today but not in a few months time), you’ll now need to do something with the internal system clock while the test is running. Perhaps you can get away with running your tests in a container whose clock is fixed to the desired time, but this is a considerable amount of work to get around the brittleness of the code itself (we will see below how to achieve this same outcome without the need for such machinery) . If something is "off" with the internal system clock (e.g. the timezone isn't the one you'd expected) and you need to make a change to your application code, ...