5 ms·
"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present
by Jach 6y ago
"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that bringing in DDD specialists on every design question is a mistake -- the use of DDD specialists ought to be to teach designers another way of doing design, then leave it up to them whether to apply it case-by-case. Same thing with TDD, the other D(data)DD, etc.
The best DDD-related thing I've read is the paper "Programming as if the domain (and performance) mattered": https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc/view https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc... One of the lessons I took from it is that too often as programmers we look at a problem and immediately try to transform it to some other problem, typically in a more abstract domain. Often this is fruitful, and our formal education (not to mention whiteboard-hazing interview practices) centers around pounding this into our heads with reusable data structures and algorithms. But also often it leads to something harder to evolve, not as fit for the original purpose, and more confusing (especially to those unfamiliar with the abstractions used). If DDD does nothing but make us challenge that default mode of thought and consider not doing problem transformation immediately every time, it's a worthwhile endeavor.
Another resource I widely recommend is the book Thinking Forth (http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/) It has many lessons applicable today on software design, including some useful thoughts on a program's "lexicon" that are somewhat DDD-related.
- radicalbyte 6y agoYou need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses. Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it. I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
- huseyinkeles 6y agoWhat is GoF book?
- detaro 6y ago"Design Patterns: Elements of Reusable Object-Oriented Software". also called the Gang-of-Four or GoF book for the four authors.
- huseyinkeles 6y agoThanks!
- dang 6y agoI don't think that history is right. Martin was talking about Eric's work and crediting him long before Eric's book came out. I saw Martin give a talk just before PoEAA came out and he was telling people to wait for Eric's book to get the richest take on domain modeling. DDD was born from Eric's roots in Smalltalk development. When Smalltalk got supplanted by Java there was a strong desire to find ways of building Java systems that could recover at least some of that development style, such as domain modeling, despite the technology being much less flexible. At the time it had sort of the feel of 'preserving what we can of civilization after the apocalypse'. DDD wasn't the only thing that emerged this way, of course. Quite a few Smalltalk programmers became influential programming teachers in the post-Smalltalk world (Fowler, Beck, Cunningham). Eric was probably the latest of these to emerge because he spent years working on that book. (It's been years since I've read it but my impression was always that it was unusually well written. It's true that you have to read it as a book to really get it, which is kind of a lot to ask nowadays.)
- radicalbyte 6y agoMartin's books formalised learnings of others - including those from the Smalltalk community - and PoEAA acts like a good map to the works of information systems. When I say that "Eric took that idea and ran with it", I mean that Eric went into a lot of detail on the Domain Model (and wrote the definitive book on it). Given the way that Fowler (and Thought Works) work I wouldn't be surprised if Eric was one of the main sources. Both books had a great impact on me, and they're both on the reading list I give to developers I'm mentoring. Properly applied DDD is extremely effective, just using Bounded Contexts is extremely valuable (i.e. taking a high level view of your enterprise, putting logical boundaries in place and accepting different abstractions in different contexts).
- kqr 6y agoI'm a big fan of Carlo Pescio's musings. Thanks for the link!