Domain-Driven Design

Type aliases are a convenient way to reflect intent in code without breaking existing behaviors.

There are many ways to modularize a system. I initially learned Volatility-based Decomposition. I now speak in more Domain-Driven Design terms. However, I consider this a change in framing more than a change in strategy.

The Single Responsibility Principle applies even to identifying sub-domains.

Looking for value objects among entity members is one of my favorite lessons from Domain Driven Design. Here’s a quick overview.

I’ve use Test API for behavior testing for more than a year now, and to great effect. I expected my recent experience with Gherkin to be similar, but found the two BDD techniques to be surprisingly different. Here I’ll contrast the two methods to highlight their distinct value.

I finally got hands-on experience with Gherkin, the common language for Behavior-driven Development (BDD). Getting started was more of a struggle than I anticipated. Here are solutions to some of my main hangups.

It’s easy to see how Domain Driven Design (DDD) by Eric Evans was such a seminal work. It presents a holistic development process that seems to have predicted the next two decades of development trends. Here are some of my key takeaways from the book.

I just finished reading Domain Modeling Made Functional. Wow, the technique in this book just feels right. It wraps up a bunch of development values I already had in a technique that is clear, thorough, and fluid. Here I’ll overview the method and recount a bit of my experience applying it.

Part 2 of Righting software presents the most complete theory of project management I’ve seen: the Critical Path Method.

Thus far this only includes the System Design portion of the book.