> But they would never give a speech about how they messed up by describing everything with maps.<p>I think this needs to be emphasized and can easily be transferred to a whole bunch of other topics unrelated to DDD/Clojure.<p>Nobody ever talks about the negative sides of some new apparently cool thing, because it is assumed that doing so wouldn't attract an audience. While in reality, often cool new thing does only work as advertised in a minority of cases and the negative sides are more important to look at.<p>We should more often talk about the negative sides of "cool" new approaches.
EDIT: my comment is wrong because it confuses Data-Driven Design and Data-Oriented Design. Thanks @Narishma for the correction. DOD is pretty great, but I wouldn't push for DDD outside game engines.<p>---<p>I see DDD as a counter movement to OOP: expose your fields, don't bake behaviors into your data structures, and accept primitive types instead of instances of the internal class MyData.<p>To me it doesn't imply "convert your code into data", which seems to be OPs only gripe with it.
I've done DDD a few times, and every single time was a mistake. The solution fit me like a glove, but nobody else really understood it. Some of my best coworkers could modify it, but they still frequently did things "wrong" and overcomplicated things.<p>I've basically sworn to never do it again.<p>I didn't know that I was doing "DDD", though. I was just trying to make it easier to make changes that I knew were common.
I don't think I could disagree with the article more strongly.<p>I've written conditional logic trees like this and they're pretty much always better than some hardcoded OOP/imperative code. I think what the author might have missed is that the conditions are labels for some functional result, usually from SQL as the app checks various fields on the user's database tables. So DDD doesn't actually work with data, but filters on data. The labels are to make the intermediate steps readable by humans, like how Prolog rules/predicates work.<p>In other words, I don't think that the article has said anything, because functional code can always be transformed to look like functions acting on conditions or conditions resulting from functions. At the end of the day, functional code is still a query composed of queries. The important part is to avoid mutable state, which would turn it back into imperative code which is hard to step through and reason about.
I googled the definition of data driven development, and none of the results I looked at explain anything. I don't know if it is because of the concept itself or because internet is becoming more and more shit
<i>whatever</i>-driven development is always just about vibes anyway. It shouldn't be taken too literally. The example in this article may have been a good use-case for Clojure's multimethod facilities.<p><a href="https://clojure.org/reference/multimethods" rel="nofollow noreferrer">https://clojure.org/reference/multimethods</a>
Let’s not confuse domain-driven design with data driven design.<p>Most architects would assign the DDD acronym to Domain-Driven Design.<p></pedantic-rant>
I like that the author points out that trying to write a new interpreter is not a good idea. However, to call that DDD, and then to say DDD is a lie is where I would disagree. I guess one could say that it's DDD taken to some extreme, but I would just call it a poor choice as the author points out.<p>Also I assume that the author is equating DDD with Data-Oriented Programming. Here's a good book on the topic: <a href="https://www.manning.com/books/data-oriented-programming?ar=true&lpse=A" rel="nofollow noreferrer">https://www.manning.com/books/data-oriented-programming?ar=t...</a><p>One thing I don't love about the book though is that it tries to demonstrate how to do DOP with Object-Oriented languages, which looks to be difficult to accomplish
I'm confused by this.
I've never written Clojure or Lisp.
I'm a run-of-the-mill C#, .NET developer.
But even I am used to treating LINQ expressions as both code <i>and</i> data.
I can take a LINQ expression, modify it if I want, compile it, and execute it against a given runtime context.
I would have expected this duality between code and data to be intrinsic to Clojure.
Hence my confusion.
How is using a function not sweeping domain complexity under a rug?<p>A complaint was that the data-driven development approach created a _poor_ DSL and then a non-DDD solution didn’t use a DSL at all…<p>What would a solution using a good DSL look like, and how would it differ from the DDD-based approach?
Yeah the Data-Driven part is obvious but the development/design... Approach? Way?<p>Serendipitous in some sort of a backwards-way that I have personally already gone that way ~a decade ago, with even func/interface-first, and the first example I found is <a href="https://github.com/drbig/ricons/blob/master/ricons.go#L57-L58">https://github.com/drbig/ricons/blob/master/ricons.go#L57-L5...</a> (it's an example, sorry).<p>As usual the devil is in the balancing, as in most languages functions won't be data but code. Unless Lisp (...that statement is superficial; homoiconicity is the word).
I am new to Clojure and I am struggling to understand what the point made of the author is.<p>I understood the Data Orientation of Clojure as building mostly map-shaped, atom-wrapped representation of application state, and then functions and procedures that operate and transact on that state.<p>The ref to the data being the "backbone" of the application (so data oriented). Is this incorrect?<p>It seems to me like he's actually criticising the "data programmable engine" (I just finished Joy of Clojure where they describe it) where you feed data to a function to change it's behaviour (as opposed to example passing in a function?)<p>I am genuinely asking.
Seems there are quite a few perspectives around this.<p>For me, "data-driven" approximately means "Something coaxed into a ~3NF/BCNF schema that the business stakeholders can simultaneously understand".<p>In my mind, this term doesn't imply any specific language or database technology. What it <i>strongly</i> implies to me is a certain modeling and normalization of the domain such that <i>any</i> reasonable business requirement can be realized within a ~constant cost factor.
A warning worth taking to heart!<p>Even apart from Clojure and so-called "DDD," there was a kind-of-recent push toward making your application logic as "declarative" as possible. Following that strategy would enable some compelling benefits, mostly related to scaling, but also enabling "self-service" for savvy application users.
I guess it depends on what you understand by this term. For me defining structA > f1 > f2 > fn > structB is easy to read, explain and modify. Never had issues with it but I did not use a lot of clojure before so maybe I don’t know the exact way.
I guess someone shortened<p>> "Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious.''<p>as DDD.
The author of DDD has openly admitted in a podcast that his book is essentially a scam.<p>He wanted to write a book about Clojure, but the publisher said that there was too little interest. So he "tricked the readership into reading a book which is about Clojure without saying that it is about Clojure". I'm paraphrasing, but that is the genuine gist of what he said (much to the non-amusement of the interviewer who must have felt deceived as well).<p>Source: <a href="https://changelog.com/podcast/522" rel="nofollow noreferrer">https://changelog.com/podcast/522</a><p>I even read this stupid book because there was a hype at work and it is so full of strawman arguments it made me furious.