X

Aggregator

CodeSOD: Driven Development

The Daily WTF
2 months 3 weeks ago

We should always be wary of "(.+)-driven development". Things like test-driven development, or domain-driven development are fine, but they're also frequently approached from a perspective of dogma, which creates its own terrible outcomes.

But let's talk about domain-driven development. Without getting too bogged down into the details of the approach, the idea is pretty straightforward: describe you domain model without reference to any lower-level concerns, so you can effectively write your domain logic in an abstract language tuned to your specific needs. In other words, it's just a pretty good practice. DDD offers tools and techniques for doing it, and as stated, can be adopted as a point of dogma instead of technique.

Julien joined a team which bragged about their use of DDD. Everything they did followed DDD best practices, they said. The fact that they piled up all sorts of related buzzwords when talking about it should have been a red flag.

Here's one of their "domain" classes:

namespace Acme\Documents\Domain; interface CakeSessionRepositoryInterface { public function isLoggedIn(string $cookieId); }

In "domain" patterns, a "repository" interacts with domain objects in your data store. Things it shouldn't do:

  • perform an authentication check
  • interact with cookies
  • care about session information
  • be tightly coupled with your underlying web framework (CakePHP, in this case)

Excluding the curly-brackets, every line in this short snippet is wrong, which is impressive.

It looks like their domain shouldn't drink and drive.

[Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.
Remy Porter