Code Smell: Primitive Obsession [video] | Hacker News Reader

Code Smell: Primitive Obsession [video]

danielbmarkham.com

Early on in the video they talk about designing specific type of "Customer" types that reflect the domain of the business, such as reflecting that Customers must be at least 21 years old to use the product.

Be very careful applying Domain Driven Design to your programs. To make software durable and survive long term, as much of the domain logic should be pushed into the user's world, and not locked into your code, poisoning it. You shouldn't need an engineer to make your program support onboarding a new type of Customer. That shouldn't require a new class and a new type. Think of the "extreme" anti-DDD software of spreadsheets. Almost every company in the world uses Excel or Google Sheets or some spreadsheet software. The business domain stays in user land, as it should. The more you use DDD, the more you poison and lock in your software into business rules that can limit the flexibility of the business, and force engineers to get involved for the business to try new things.

wdym user's world?

A ‘new type of customer’ could mean all sorts of things. In my mind it means a new sort of business for the company. It doesn’t seem crazy to me that software work should be required for a new kind of business—there would surely be new contracts needed from the legal department as well as different marketing and possibly accounting or billing. And if nothing new is needed, perhaps they aren’t really a new kind of customer after all. The DDD way to handle customers who must be over 21 is to have some type for the input of your business process, say customeOver21, and some function to which you give a customer and get back either a corresponding customerOver21. This makes sense if the kinds of customer are totally different but if, for example, you are a shop and some products may only be sold to customers over 21, then you probably want some different logic instead (eg each item may correspond to some requirements on the customer (or even some other state, e.g. max 2 of this item per customer) and these requirements can then be unioned together for all the items in a cart.)

But however you do things, I think you should work hard to ensure that it is easy to avoid accidentally treating, eg, a customer id as a transaction id or SKU id.

Excel just has a different domain: “people who want to write their own programs to solve … problems” or something like that.

"Domain" is an undefined term, which is part of the problem of DDD. It's an arbitrary grouping of things. Sometimes people use it to mean a part of the business, sometimes it's a group of models and actions on those models, and it's all a fundamentally flawed attempt to divide the real world into categories. It leads to ambiguous groupings of things where it's not obvious to put new functionality. And those groupings poison your software by trying to lock in very specific business ideas into software, making it inflexible. Excel is designed around _functionality_, and pushes concepts of "domains" into the users of the software, using it however they want to design their domains. If Excel had a "problem solving user" domain and a "business account" domain, etc, it would be terrible software.

I think the analogy is to “domain” meaning “the set of valid inputs to a function”. A business domain is the set of entities a particular piece of software is designed to work with. It’s a fuzzy “philosophical” term, but it’s not useless and paying attention to these seemingly arbitrary concepts makes a system much nicer to work in.

> "Domain" is an undefined term

No, its not.

> It's an arbitrary grouping of things.

No, its not. Its the conceptual space in which the problem exists that software is solving.

> Sometimes people use it to mean a part of the business

For business software, this is approximately correct (its the part of the business context addressed by the system under design, which usually includes both some aspects of the business and some aspects of the universe outside of the business with which the business interacts.)

> sometimes it's a group of models and actions on those models

This is fairly explicitly wrong; that's a domain model, though confusion between models and the space being modeled is one of the most common cause problems in software engineering.

> and it's all a fundamentally flawed attempt to divide the real world into categories

Arbitrary, perhaps, but the divisions of the real world into “things the system under design is concerned with” and “everything else” is pretty fundamental to constructing a system.

> And those groupings poison your software by trying to lock in very specific business ideas into software, making it inflexible.

No, the groupings involved in defining a domain do not. There are other levels of analysis in DDD where that might arguably be the case, e.g., the assessment of consistency boundaries, but that's a different discussion.

> If Excel had a "problem solving user" domain and a "business account" domain, etc, it would be terrible software.

No system designed with DDD has multiple distinct domains.

This video format is challenging to watch. It's one presenter with a (co-host? I haven't seen this podcast/show/whatever before), and they keep going off into "oh you know what that reminds me of". The tangents seem like they (or at least the co-host) is showing off "this is what I know" and it makes the main message really hard to follow. I'm 30 minutes in and I'm giving up. Two people talking over each other takes away from the presentation / main thread.

Interestingly, this is OOP advice that if generalized, applies pretty directly to functional programming. In my mind the fundamental problem with using primitives is you’re overloading the meaning of existing types, you can use them in the wrong places and the type checker of course can’t catch those misuses. You’re stuck with functions/methods that may be applied even if they don’t make sense.

This is very much analogous to failure to use newtype wrappers in Haskell-like languages to differentiate distinct uses of existing types. Same symptoms, same underlying conceptual issue.

So much this. Strings can contain anything… json, JavaScript, invalid utf8, you name it! I’ve seen type systems (poorly) re-implemented in already typed languages around string usage.

Full disclosure: as a young programmer I contributed to and was co-responsible for promoting an in-house Java library which misused strings in exactly this way. I didn't know any better, I was working with some people who only knew SQL and in the relational schema every column was type char or varchar.

I too have gone back and looked at code only to think, “what idiot wrote this?!” … when I slowly realize that I’m the only author. Experience can’t be taught. :)

“The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.” - Alan J. Perlis

At least today we have string types which know their own length and character set.

Two strings walk into a bar and sit down. The bartender says, "So what'll it be?"

The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu"

"Please excuse my friend," the second string says, "He isn't null-terminated."

Don't use broken Regexes like this one to validate email addresses.

Isn't this another variation of "parse, don't validate"?

Except that your strings are no longer strings. DDD value objects, thanks but no thanks.

Code Smell: Making Everything an Object

>Name = name;

This is so wrong, why not use newname for a new name value?

Being clever like this is exactly why I stay away from C/C++ and other case sensitive languages. They encourage pendantry.

Reply on news.ycombinator.com