03:14 - Domain Driven Design04:01 - Domain Model04:09 - Patterns of Enterprise Application Architecture by Martin Fowler05:24 - Domain Driven Design by Eric Evans

• Growing Object Oriented Software Guided by Tests 07:54 - Ubiquitous Language: Use the Terms That the Business/Users Use in Your Code 08:50 - Bounded Context 09:50 - Pattern Language 10:03 - Repository: Allows You to Retrieve Things 10:21 - Entity: Something With an Identity
• ActiveRecords 14:28 - Refactoring14:28 - TDD (Test Driven Development)14:47 - MSDN Article on DDD
• Wikipedia Page on DDD
• Podcast Interview with David on DDD Part 1, Part 2 15:05 - SOA (Service Oriented Architecture)16:51 - Anti-corruption Layer
• Scar Tissue 19:03  Smalltalk Best Practice Patterns by Kent Beck21:56 - Objectified (documentary)24:00 - Domain Model vs ActiveRecord
• ActiveRecord (The Design Pattern)
• ActiveRecord (The Rails library) 26:20 - Objects on Rails by Avdi Grimm27:33 - ActiveModel29:49 - Aggregates (Domain Model Pattern) 32:54 - Domain Specific Languages
• A Good DSL Has a Strong Semantic Model 34:23 - Cucumber35:45 - Gherkin39:01-  Project Glossaries / Dictionaries 41:33 - Javascript Jabber Episode #18: Agile Development
• Domain Language 43:57 - DDD leads to simple design
• MSDN Article by David Laribee 46:58 - QCon Book 50:11 - Spiking Code 52:24 - The Pragmatic Programmer by Dave Thomas and Andy Hunt

Transcript

AVDI: So Linux received a Skype upgrade. I think this one is from 1995. JAMES: Wow. CHUCK: Yey! JAMES: Jeez. So current. CHUCK: I have the most recent version of it. I think its interface is from 1995. AVDI: Hahaha! JAMES: Agree.[This podcast is sponsored by New Relic. To track and optimize your application performance, go to Rubyrogues.com/newrelic.]**[Hosting provided by Blue Box Group. Check them out at bluebox.net.] **CHUCK: Hey everybody and welcome to Episode 61 of the Ruby Rogues podcast. This week on our panel, we have Avdi Grimm. AVDI: Hello from sunny Pennsylvania. Just a quick reminder, my other podcast wideteams.com is going strong. I’ve had a ton of interviews with awesome programmers working remotely in a distributed team. So if you do that. Please check it out. CHUCK: Awesome. AVDI: Ok, I’m done. CHUCK: We also have James Edward Grey. JAMES: I’m mostly dead today. I’m very sick so I will try to contribute between coughing. CHUCK: Well, if you’re mostly dead that means you’re slightly alive. JAMES: True. If you’re all dead, you have to go through their pockets and look for those changes. CHUCK: That’s right. We’re gonna do another princess bride episode. I remember that one; that was fun. We also have a special guest and that’s David Laribee. DAVID: Hello! Coming at you from Hotlanta. CHUCK: “Hotlanta” huh? JAMES: How hot there? DAVID: It’s getting hot in here. Something 95F. CHUCK: Oh was that all? JAMES: We’ve been over a hundred for three days now. DAVID: Really? Okay. Well, Temperatelanta. CHUCK: [laughs] You wanna introduce yourself, David? From those who don’t know who you are. DAVID: Sure. I work for VersionOne. I work in a product development team. I am the development coach. Kinda like a tech lead, I suppose. I’ve been developing myself for 15 years, across a wide variety of industries. Mostly lately have been in the Ruby and JavaScript kinda world. So, polyglot. I do conference speaking, seen in the road occasionally. CHUCK: I have to ask who‘s weirder, the JavaScripters or the Rubyist?? DAVID: I don’t know. I mean, I think that there’s a lot to like about the stuff that’s happening in JavaScript, especially in Node and CommonJS and stuff like that. I kinda like both communities. I actually kinda like the Java and .Net community as well. So, I think there’s something weirder? I think probably Haskell people are the weird or Erlang. You know, I don’t know. But weird in my book is a desirably a good thing. CHUCK: All right, cool. I’m Charles Max Wood from teachmetocode.com. I guess its devchat.tv.com now since I’m gonna be getting that up within the next week or two. But if you wanna check out what I’m working on, go to buildingjasonapis.com and sign up for the online training. It’s gonna be in two  weeks. All right, well let’s jump in. Let’s talk about “Domain Driven Design”. Is that correct? JAMES: Yeah, but it was just on our calendars. It’s just DDD and my wife kept asking me what it is. CHUCK: Did you look at her and go, “Duh, Duh, Duh?”. JAMES: Hehehe. It’s awesome. So, domain driven design. Can you give us the ten thousand pitch, David? DAVID: Sure. Well, I think it’s essentially a collection of approaches. Approaches could be patterns, could be heuristics, could be rules, such as the solid type rules around taking the real value and complexity of your business logic and crunching it into a pattern that people might recognize better than DDD, but it’s called domain model. Domain model, being a pattern that’s kind of popularized by Martin Fowler and patterns of enterprise application architecture book. It’s just a way of structuring DD core value or core logic of your application. Now, it’s quite thick book and it’s quite dense and it’s kinda organized in a principle. There is a series chapter that gives you a tip or approach or a pattern or a method or an example of how to properly construct a domain model. So, I’d say kinda one really reductionist way of putting it, it’s a bible for creating domain models and it goes quite deep as far as how to put domain models in context with other domain models. How to isolate the… tips for isolating things that should go and should not go in a domain model and I think we’ll kinda dig a little bit deeper as our conversation goes on, but that’s more or less how to construct a domain model. It’s a very reductionist way to put it, but I think that’s a good starting point and then we could get to them some more subtle  aspects. JAMES: So when you say bible and big book, you’re talking about the DDD book not the Martin Fowler book? DAVID: Yeah, right. So Eric Evans wrote “Domain Driven Design”. He came up with the term; it’s his baby. The book is pretty old; its 2003, but it still gets quite a bit of attention - The idea of domain driven design in the book. It’s like I said, dense book. It’s written in kinda Melvillian way. I think it’s well written, but I think there’s a lot of information in there. It’s not uncommon to find people at this point that read it a couple of times. I don’t think that’s any fanboyism thing. There’s just so much information in the book like that you see in a long movie. Sometimes, it benefits you to see it twice to catch the details. That’s very much a phenomenon going in this book. So Eric Evans, he’s the guy that kinda came up with this whole approach. It’s one of those driven development things, one of those DDs. But it’s a good thing for developers to check out, especially I kind of notice in the Ruby community, there’s a new sensitivity to object oriendted programming that is meant present in the Java community for quite a while. I think that this is a big part of that pie. It’s a big piece of that pie, the domain driven stuff. So, it’s similar to test driven development, like the fast test and the super isolation kind of like “Growing Object Software Guided Test” approach. This is, I think, another angle of attack and a worthwhile thing for rubies to check out. Anyway, I’m rambling but Eric Evans, he’s the man. He’s responsible in a large part for this and there have been a lot of people that kinda picked it up and taking it in a new direction and started practicing some of the guidance that he’s put in there. So, there’s a bit of community around it. I think there’s a Yahoo group or Google. I don’t follow it anymore, but there’s a pretty vibrant group. There was a pretty vibrant group around it. CHUCK: So, not having a lot of time to dig into this. I’m a little curious, is it more of a set of prescriptions or practices or is it a set of principles that you attempt to follow? DAVID: Well, it presents a pattern language so we can start there, but I don’t think that’s the most…Well, let’s start with the most important thing. I think in DDD the two most important thing, are “Ubiquitous Language” And this maybe something we take for granted, but this is the idea that when we’re speaking with our customers, we are speaking with our users. The terms that they are using will also be reflected in the code. So, it’s about removing that impedance mismatch between the language that the business uses and/or the language that our users uses and what we name our classes. That’s one thing and I think that’s something we take for granted, but that’s something we strive to really as developers: look at what we’re naming things and try to really listen to what the users is saying and have that reflected in the code. So ubiquitous language is one big kinda explicit thing  that’s in the book. The other thing is ‘Bounded Context’ and that’s a notion that, we wanna focus our domain models down to the essence of what they do. And that, it’s okay to  have multiple models working together,  but there should be some notion of a boundary between that. We don’t want them to leak in to one another. I’m sure you guys have all seen massive ActiveRecord situations. Right? With tons and tons of models and it’s just all coupled together, that kind of thing. That’s a no-no in the DDD world. We don’t wanna see security or little security system intermingled with our shopping cart stuff.  We don’t as well wanna see our shopping cart intermingled with our product catalogue. So those would be distinct models. Maybe, right.  That’s just an off cut example, a typical bad example, but bounded context is another important notion. Now, we can talk about what goes in the model and in the book is presented a pattern language for constructing a domain model. In that pattern language, you have things like.. We’ll start with the pattern that people focus on a lot when they start to get into DDD, but it’s only this important one is repository. A ‘Repository’ is just a type that will let you retrieve things. So it will let you retrieve things. A little you save things to access kinda looks an in memory collection. It may be backed with some kind of persistence thing. Okay, the next thing is an ‘Entity’. An ‘Entity’ is something within identity. Now, if we contrast this with like… Usually, identity have a lot of cycles, but if we contrast this with an ActiveRecord where the repository is implemented as kind of class methods. An entity, this are like instance methods because it’s instance. But it’s all in one thing right? JAMES: Yeah. Let me speak to that for just a second. When I was reading yesterday, all this DDD stuff, I was listening to the ubiquitous language stuff and you’re right, the ActiveRecords kind of design that way right? I mean, we do “some model”.new and we pass in some field and that sets it up, and we end up calling something like, ‘save’ on it which may be isn’t very descriptive, you are talking about with your big with this language. It might be better to have some model that validate request or whatever that speaks more to the domain that what we are actually doing with. I’ve been eventually began using to working that way.  The last couple of months or so, what I do is, I’ll just define class methods on the models and then I’ll have class methods for retrieving records. However, I would like to retrieve them and for saving some method however I would like to save it. I would just call update request. I might pass in some parameters or whatever. It creates that model to save all that inside that method. And that lets me basically treat ActiveRecord just like a persistence layer and not bury it with a ton of model logic. So does that makes sense? DAVID: Yeah, that makes perfect sense. I think that’s really great because what you are starting to is, you’re starting to tease out bounded context. You are trying to remove like one context is persistence. That is one aspect of what the application does. It’s a cross concern. Everything probably, “Where do objects go to sleep at night in the database?” So you’re trying to tease that out, pull that out and I think that’s really good. So, I’d ask you James, “Do you find that in your code like in your controllers or wherever you’re accessing these models. Are you getting that is it becoming more expressive? Is it easier to see what goes on? Is it something that potentially could sit down with the user and especially in a language, like Ruby where once that they can’t get over the fact that dot is the maximum passage argument?” They wouldn’t think of that of course, that way, but they could read it and it would make more sense. I mean, that’s the name of the game. JAMES: Yeah, that’s exactly why I’ve been doing it. I mean my controllers now, instead of some model dot new and then some instance that update attributes whatever and an if, now, I could just call methods on the model that are named after the operation that I’m actually doing there and then passing what it needs to do that and inside the model, make instances itself and save them or whatever for cross cutting concerns or things that are tagged to persistence. I make normal Ruby objects and deal with it that way. DAVID: So I think that’s exactly the kind of benefit that DDD that tries to bring to the table. That there’s so many little nuggets and a lot of them are just kind affirmations and I do instinctually as I stumble across that, but it’s nice to have a name for it. It’s the same value as a patter. But then there’s a lot off for me anyway which was fairly early on. There were a lot of ‘aha’ moments in there. That little hacks that when you add them all up and you take the basic principles, you ubiquitous language bounded context, you get a lot more expressive code, you get codes easier to maintain, you get code that’s more susceptive to changes. Pairing this with something like refactoring and TDD, you get a more immutable object oriented code base. JAMES: Let’s talk about your bounded context a little bit. The more I read about these… I guess, I should  clarify that I just really read that msdn article and then the U road and then I look through Wikipedia and I listen to a couple of podcast that you’re on and I put links to those on the show notes. But when I hear you talking bounded context,  always my mind is drifting to SOA and I’m wondering, if that’s like a common comparison or do you lean towards SOA type arguments or setups? DAVID: I think the notion of how a bounded context is implemented, I like to think of as distinct from the concept of bounded context script. I like the low file approach and I think if we just have one application, which is a lot of people are just working at one app. Like having a rest API behind fronting services might be a bit of overkill for a lot of people. So in that case, I would look for a more services, maybe just use a service object or a façade between models. And I think it might be better to just use it in process, class or object to isolate the models. That might be a more a cost effective low file way and you could evolve that later into something more specific. So,  just adding a some kind of abstraction unit in its memory thing. I’d rather keep it that way, especially as you’re learning, “Is this really a  primary way that needs its own infrastructures? It’s own  API, it’s gonna be multiple consumers of this thing. I think that’s where I kind of look for that solo stuffs. I’m not by all mean an expert of that, but that would be my gut reaction. For the purpose of this conversation, let’s treat bounded context. You wanna try to identify where they are and you wanna just keep a little boundary behind them. One thing that goes with this is this notion is this pattern in the book anti-corruption layer. And this I think people use all the time. Have you every head to call out to web service application you , Chances are ‘yes’ and so, you typically have some kind of adapter over that web service .Right? Some kind of interface that you control. Now, that’s very much in the anti-corruption layer. Right?  You don’t wanna leak in all these calls to that external API which might change. You wanna constrain that into one box. So, if we have model that needs to call another model typically we have anti-corruption layer. If we have a model that needs to do persistence, we have some kind of thin ant-corruption layer that delegates to the persistence layer. AVDI: I heard someone recently called that a ‘scar tissue’. That you sort of build up around external dependency. DAVID: I think that’s a great metaphor. CHUCK: Because you wind up cutting yourself on it a few times. JAMES: It strikes me that a lot of these things that are talking about are nice to mention. New concepts l mean, like you’re talking about right now a boundaries of system and we definitely have lots of patterns for how to deal with that; you’ve mention several. So would you say that, DDD kind of took a lot of existing concepts, maybe added some of its own or spun some of a little different way, or combine and kinda took some of the best of the best object oriented programming and try to distil it down to a related thing? DAVID: Yeah, I mean, I think a lot of it is editorial. I think that any kind of book that is editorial there is new content generated in the editorial.  As far as how you stack it, how you present it and then, there’s a fair amount of new content in there right. So maybe we’ve been talking about stuff that is like, I think ubiquitous language is a pretty novel concept. I think it’s very much making the implicit/explicit type thing. JAMES: We did small talk best practice patterns as a book club book at one time where we read that. So that’s an old book from a SmallTalk days and it definitely had a lot of patterns in there that I would say put together probably for ubiquitous language attention revealing selector which basically, just means you know, choosing a method name that reveals what you are trying to do and hiding the code that actually does that behind that thing. DAVID: Right. JAMES: So, I wouldn’t say, I mean,  we’ve known for a long time that naming is one of the famously hard thing to the computer and we’ve always struggled to do it. DAVID: It gets a little easier when you listen to the language that the business uses though. I mean that and there are traces and smell things that there’s nothing new under the sun. And Ruby is, you know, how old is it? It was 1995 or something 94. JAMES: Yeah, 95. DAVID: Lot of the stuff that we are using is pretty old, but I think DDD kinda condenses it down pretty good… It’s not a system, it’s not a systematics thing or a process but it start with imagination. It’s a kind of a cache of knowledge that brings a lot. It sure brings a lot of stuff that exists but I think it presents it in a way that is pretty enlightening. JAMES: Sure. DAVID: For specifically old people, I talked to Eric. It’s not limited OO and stuff, but the book is kinda presented in Java, in a kind of class oriented language. So I think that when I say,”OO” that’s how I use it or I just take it to that. You could apply a lot of these techniques in a functional language or different paradigm but I wouldn’t knock it just its editorial. JAMES: No, I wasn’t knocking it at all. I was more like its standing on the shoulders of giants. DAVID: Oh for sure. JAMES: It’s taking a lot of things that we use. My other impression just from looking  through the stuff that you send was that, it’s seem to  address things at several levels, like on one hand it seems to be a strategy guide kinda overall kinda high level strategy, but then in places it seems to get into tactics which is much more smaller focus, how to rehandle this little bit. Seems like it kind of tries to build up an overall… I can’t think of a good word right now, but an overall plan that hits at many different levels. Wouldn’t you say that’s true? DAVID: Yeah, I would say that’s true. There’s a movie I like called Objectified, it’s a documentary from the dude who did helped Helvetica and it kinda details industrial design. One of the people in the movie makes a point that there’s hundreds of definition for the word ‘design’. So I think domain driven model design, the word ‘design’ is a very important thing. This is one approach to designing.  So in software, there are levels of design, you could be designing a method and that’s a very tactical pretty low level thing, but there’s a number of things that you wanna take into account when deciding that method. You could be designing collaboration between classes and that’s a little bit higher level. And then, you could systemic level, maybe architectural level. I kinda don’t like that term, but a level where you’re talking about major components or packages working together. I think that there’s guidance and tips and advice and ideas about how to work across those level s and as developers, we found ourselves constantly moving up and down that stack. JAMES: Sure. DAVID: The other thing I’d say to kinda put this in context is for me,  domain driven design informed my approach to design as has test driven development, as has a number of things you know. I think it’s not  necessarily a term ‘key’ solution. I just wanna make that plan I think it’s something that it informs the way you design systems. CHUCK: Right, I’m a little curious, have your run into situations where DDD maybe isn’t the best approach? DAVID: Again I think it’s not a full on approach. I think that I use something from DDD and pretty much everything. Let’s reframe that question and lets say domain vs. ActiveRecord. There is a kind of a choice, which one are you gonna use? And I think,ActiveRecord is fine for some simple of applications or forms over data. We find that might break down when we start to think, about more complicated systems and when you choose domain model, you tend to have a more complicated domain, more complicated business that you are working with or more complicated problem. JAMES: I just wanna stress that doesn’t have to be a dichotomy. Right? It does not have to be domain model or ActiveRecord. We can build domain models and then use ActiveRecord as a persistence layer or something like that. DAVID: I mean you can, I mean that there are I kind of see them… So, ActiveRecord the library in Rails? Yeah you can use that as your persistence mechanism. The pattern, I kinda see as  somewhat of a dichotomy. JAMES: Isn’t the pattern just pretty much define how those classes map to the table? I mean, does that really say anything about how you should model your application? DAVID: Domain model says nothing about persistence. They are kind of of different things. JAMES: Yeah, right. DAVID: It’s the ActiveRecord, its logic plus persistence together. Domain models over simplifies says, logic and then there are other persistence patterns. I guess maybe we’re in a violent agreement. JAMES: Yeah, I think so. I don’t know. It’s been a long time since I’ve read the ActiveRecord pattern so I definitely go back and read it. I don’t’ know that it’s necessarily says that the object and the persistence are the same thing. I think it defines a way to persist objects, but I don’t know that the pattern itself says that you’re logic is tied to that same thing. I may be wrong to that though. CHUCK: Yeah, but ultimately don’t we typically do that with the ActiveRecord library? JAMES: I would say that’s the way that is commonly use, but I definitely think that there’s people that are pushing the boundaries and trying to get away from that. I mean even Avdi’s Objects on Rails book, he takes a casual approach if not going a whole way or anything like that, but he is showing ways to break logic out of that ActiveRecord trap. AVDI: Well, I try to start outside ActiveRecord. I start very, very explicitly with domain model and domain language and just completely ignoring the language of ActiveRecord and then I sort of added in the background as I need it, but it is difficult sometimes to break those ties. I mean, the fact that just little thing like the fact you’re using it, then you are dissenting your objects from ActiveRecord base; the bigger things like validation, I mean a validation can very much be part of your domain model, but it’s very much part of your domain model. But if you’re gonna use ActiveRecord validations, you’re gonna be using them in the ActiveRecord way, in ActiveRecord of language. Although, at least they’re sort of extracted out of the Active model now. But there are aspects of it that can make it a little bit tricky to kinda of tease that out. And honestly, you know something that kinda bothers me to this day, is just the whole process of saving objects. A lot of times I feel like, if we really talk in domain terms , then saving isn’t really something that pops set up in domain language very often. You buy a book, you don’t save a purchase, but you’re writing a code to do that very often, saving the purchase is exactly what you do and it could be a little difficult to get away from especially when you need to change a number of models together. I mean, I often wish that I could just do something where I change a bunch of models and then at the end of the request cycle, something magical goes thru and collects up all the models that have changed and persists them. I haven’t really gotten to that level yet and sometime I feel like ActiveRecord is holding me back from that. DAVID: You could just switch to Java or .NET. *laughter\ *DAVID: So I don’t know if you’re gonna wanna take that. AVDI: [laughs]. DAVID: You could think about the trades off. AVDI: Next week: “Welcome to Java Rogues”. JAMES: I think it’s actually was a good discussion. I think what we hit on here (I'm just trying to summarize and tell me if you don’t agree), but I think that it is possible to at least in some cases, separate a pattern like an ActiveRecord and then your domain model concerns. But maybe what we did say in discussing this was that, ActiveRecord tends to push you towards that path a little of keeping that object inside of it and maybe that encourages us to build apps that way. DAVID: Right and I’ll agree on that point. I want to also make... there’s one I think really good example of the difference between domain model and ActiveRecord and that is that with ActiveRecord, things are more...  well, recordy right? You have a, fine, say blah blah for every pretty much record, right? And every record... In domain model, you have this thing called aggregates, this comes from domain driven design, but with aggregates you have more, you think about things in term of trees, right? You have a root, aggregate root, so in a case of like a customer, lets pick the typical bad example of customer orders orderliness. In case of like order, orderlines its part of the order aggregate, an order has one to many orderlines, in that case you typically wouldn't see a repository for orderlines, you just see it for order. The order repository would say the whole graph. I think that’s a different thing. Now, there’s other rules that are important about aggregate that give you value in OO space, specifically anything outside of order, the order aggregate cannot hold a reference. Yhis is kind of a guideline thing, cannot hold a reference to one of the sub, right, so if I’m a customer and I can't hold a reference to an orderline, that makes no sense, and this is why this is a bad example. But there are examples that makes a difference in something like coupling. Your order would have something like amount, which would then iterate through the order lines and grab the sub amount, or subtotal, or the quantity times price, or whatever, probably that being capsulated in order line. But that notion of, you would say, order an amount, and that you would couple to the aggregate root but never one of the children of the aggregate. So I mean, that’s an example something that seems fairly subtle but we haven’t talk about persistance and all, and once we start, and typically like in a .NET world, you something like hibernate and you could just go create mappings between every single objects. In reality, you’ve got this framework that handles  it for you but it’s completely outside of your code, there’s completely no tax on the code necessarily, there’s no sub class, there’s no, you know, imperative stuff. There’s nothing you need to really do. JAMES: I don’t know if I totally agree with that, I’m Java certified and I think we can call Java a tax. So... DAVID: Yeah, right. CHUCK: [Laughs]. DAVID: Right, right. No, I'm not advocating it. Believe me. I love dynamic languages I’m a big… you know I would choose that... JAMES: That right, seriously like what you are saying there about, you know, how the way the ActiveRecord, it kind of puts a blockade on the road in even thinking about aggregates, right, it can... DAVID: Right. JAMES: Does putting a barrier there. Let me ask you this. Going back to the ubiquitous language thing. How does DDD feel about domain languages? Because in Ruby that is a common tactics for us is to first morph our language into the language of the problem and then solve the problem, right? DAVID: I think having done a fair amount of DSL development, I think pretty much any domain specific that you make will benefit from a strong conceptual model, underneath. So typically your DSL is kind of a near over some model underneath that exists. So look at like Rake, there’s tasks and there’s classes that represent these things that you're just using, kind of Ruby syntax sugar to orchestrate. And then there’s usually something that will take that and then build those things that would interpret that DSL, an interpreter that would interpret that DSL into the terms of I said conceptual model, and I meant to say a semantic model. A semantic model applies things like DDD will help harden that up. So I think that most DSLs, you don’t just have a method that reads error, most DSLs are backed by some kind of model. JAMES: Yeah absolutely. DAVID: That backing model is where you would applied DDD. I think applying some of the ideas in DDD. And persistence is not a DDD idea, so let’s just take that off, but some of them create an elegant model that reflects the ubiquitous language of what you’re doing, if you apply some of those things your DSL will necessarily reflect. It will become better. It will become easier to manipulate, easier to model, easier to move around, to add things to, etc. JAMES: So are you a like a big fan of things likes Cucumber because they allow us to test in the language of the domain? DAVID: In my current job we do use Cucumber. I’m a big fan of Cucumber because if it were just three developers working on a problem, I probably wouldn’t reach for Cucumber but when it's like a whole team, and you got project managers and testers, and things like that, I think it's a great way to involve that team in the process of collaborating through an effort. I do think that it is important in our Cucumber I kind harping on is this language we do use in the feature. And in the feature area, we use the opportunity to describe definitions and terms that enter the ubiquitous language. We're working in the domain of agility so some of these things were kinda making up, what's a track epic, what's a root epic, well, that’s really our thing. But that’s the thing with ubiquitous language, so it’s a really great question because you see it not only on your code, but you hear it coming from everyone on your team and everyone you talk to, and you talk to customers, you hear, you should see it if you’re using Cucumber. That kind of thing. It should be pretty consistent all the way, down the line. We wanna avoid developers having to become interpreters or human compilers, were not just there to like interpret the solution that customers give us and then we encode that into machine language as far us they know. We are there to help them collaborate through and understand and we become little subject matter expert as time goes on. JAMES: It’s kind of an interesting. I’ve heard you before say that our job is basically translators. We exist to translate between some business ends and things computers can understand. DAVID: One out of the job, right. That to me that’s an awfully dim idea… I think that it’s scary, it’s not fun at all. I think that’s not a way to use a smart person. CHUCK: I agree, you don’t want to use him to cross-compile English into code; instead what you want to do is... I think you really hit the nail in the head when you said you become many subject matter experts, and that's something that I’ve seen in the few of the jobs that I’ve worked. You really couldn’t build what was needed unless you understood what it was doing and not just from the fundamental shuttling  data around, but actually understood why things had to be the way they were and what was being discussed on the business end when they were talking about what they needed next. JAMES: Yeah I think I was using a more bruised definition of translator, I wasn’t meaning so much that they would say you do this, this, and this, and we just right the code with that exactly. I mean more we say things like, “you can’t really say that in computer speak but instead we can do this thing which is kind of the same thing” or how would we go about that, or you know maybe translators  a bad word, more like a ‘guide’, right, we’re guiding a process into the area. DAVID: I think we all have our specialty. When we worked with customers they kind of internalize their business sometime it can be really hard for them to verbalize, cause they just internalize, it’s just that they live it. So having to explain that can be an impediment, but that’s really their forte is, knowing how their business works. And obviously as developers, our forte is knowing how... were technologists, we know how technology works, but I think some like DDD can help smooth the continuum of how things happen. And I think that most developers are really smart people that can really benefit, thinking through, maybe the way this works is not necessarily ideal, or we need to work on how this is expressed, or I’ve got some really good questions that are gonna yield the better solution, right. I think DDD helps some of this stuff, and then helps and smooth that continuum a little bit you know kinda keep it... AVDI: I’m just wondering do you ever compile some kind of project glossary, with domain language outside of the code? DAVID: If it’s an important term that isn’t in the vernacular we will use Cucumber to document it in situation. As far as distinct glossary, I have worked in an insurance before and a pretty complicated domain and we did have like a page on our wiki, where we would keep some more complicated terms for new developers like *** and controversion, things like that that are pretty important to what we were developing. But not comprehensively or as a rule, I think you want it to be more of a social cultural thing. It’s in the language you use back to the ubiquitous language, it’s in the code you use. It just permeates the environment. AVDI. Yeah. Now I was just thinking on projects the we were on that we were sort on a learning curve where you have to use this language that’s permeating the code but you’re not particularly... it’s not immediately obvious what those things are. DAVID: Yeah. AVDI : And its... it can be obvious, like some of those words that (I can’t even probably pronounce you moment a ago), those are probably obvious cues, that as a new developer I need to go get some help. I need to go get definitions. Sometimes you see stuff though that it seems like every projects has something like in it called ‘item’. Chuck: [laughs]. AVDI: And it means something different in every project. JAMES: Oh, yeah the item. You know, the item. AVDI: Yeah. CHUCK: And then you get the other ones that says ‘order item’ because it’s an item attached to an order because that's more descriptive. DAVID: Better than ‘meta item’. AVDI: Oh no don’t get me started, I worked on a system that had item def, item ref, and item datem. DAVID: Nice. JAMES: Wow. DAVID: They invented their own object system. Sweet. AVDI: In that context, actually meant question. JAMES: And that domain was a candy store, right? CHUCK: So I have another question regarding DDD. Since it’s about ten years old now, and this is stemming from the discussion... JAMES: We need to stress though that it’s newer than Avdi's version of Skype. *laughter\ *CHUCK: Gotta love Linux... anyway so we have a discussion about JavaScript Jabber about Agile development and one of the things that came out was that, even the ad hoc processes that companies follow when they are not really well versed in Agile they tend to reflect a lot of Agile principle and DDD having been around in the last ten years, have you seen any of the concepts or discussion points for DDD kinda creep into popular development practices? DAVID: Sure, actually Eric’s kinda came out  with something he calls ‘world pooling’ which is a kinda putting DDD into the context of intertie incremental development like Agile. And I encourage you to check that out. I think its domainlanguage.org, we can put that in the show notes hopefully. He has lots of experience of being how this fit into some sense of rigger, some sense of process. I just see it as perfectly compatible with Agile. I think what you have is a story which is users story which is kinda an invitation to have a conversation. And that’s a great way to set up a conversation between someone that knows a lot about the business and someone who knows lot about technology and is really trying to represent that business appropriately in a model.  So I think you’ve already set that context for success. I think that as far as process goes, a lot of mature Agile teams… I’m a big fan of the Dan quote that the only three best practices are learning, experimentation and situational awareness. And I think we kinda get hang up on the orthodoxy of things and may be try to adopt things that aren’t necessarily appropriate in the code base working on the business that we’re working with. But I do think most successful Agile teams kind of own their process over time. They will become their own and they’ll pick the things that work for them with their values. If  you value just simple design in like moving things forward, something like DDD works perfectly without really any kind of stress on the process or your practice. If you value things like cleverness and inventing things that are proprietary and stuff like that and XML, then I don’t know that DDD is necessarily the best approach. And there’s of course a value of judgement in my description of the latter set of values. I feel like I’m rambling, I think it works fine with Agile, it works great with XP and with XP comes from the object oriented bigotry kind of perspective. We’re just gonna straight OOO they’re small talkers that invented XP. I think that DDD works great in the OO paradigm. I do kind a look at it as Eric, talks about crunching knowledge in the models and that when you have this Aha moments about understanding what goes on with the business, that could happen in independent of the user story and you might find some difficulty there, but I think pragmatic Agileist don’t have a problem in bringing some kind of design change in a back log especially in a high trust environment where your customers are your product owners, your product manager know that you’ve proven out that you make good decisions about product. JAMES:   Yeah. I think that makes sense. DAVID: I’ve  like little five process , that’s just kind of I think what I’ve seen worked and I’ve done Agile coach and that’s where I tend to steer teams toward. I think developers don’t… JAMES: Yeah, that was kind of one of the… I guess, I don’t know If I it call ‘complaints’, but just getting in DDD and looked over documents and stuff, I guess I felt like I just barely gone down the rabbit hole. It is kinda deep and there’s a lot in there and stuff and that is not something you casually you get into. You have to work your way down. CHUCK: Is there’s a good starting point. Is the book the best place to start or are there are other places where you kinda get your feet wet and really get a handle of what DDD is about? DAVID: I hate to self-promote but I think that msdn article I wrote isn’t bad. I think it’s a pretty good primer and you’re talking 4,000 words vs. 60-50 or something crazy. That should’ve less at least let you kinda, “hey is this something might be interested in?”. And there are a number of links that we put in there, everything that gonna cover me is gonna be short pretty short, quick. There’s QCon book that gives you some of the primer stuff and it is fairly short as far as evaluating. It’s this something that you should learn. If you’re out of books, just read this book. I’m a reader, c’mon just suck it up. CHUCK: This is a lot of books. AVDI: That was I gonna say. DAVID: If the books in your shelf. You’re sick of the books you’re currently reading, pick this one up. Why not add another one to the rotation? I’ll give you some more at the picks portion. I checked out that MSTN article; I’m pretty happy with the way it turned out and there are some issues as far as how much effort they put it in into editing that article, but it gives you the gist and you could read it pretty quickly. You could read it in one sitting, one very short sitting. So beyond that, I can’t really suggest anything. Perhaps, start with the Amazon comments to see what’s going on there. I know people that have bothered to read it and have have gotten through it come out somewhat changed with a set of insights. So, I think the value is there as far as reading it. You will get a couple ways of talking about things or a couple of affirmations or you’re gonna get a couple of new ideas to try out. Like James said, may be on the small ways like your ActiveRecord stuff. So I think the value will be there for pretty much anyone reading it. You don’t have to take my word for it; you can check it out yourself. CHUCK: Awesome. All right. Is there anything else we want to add before we get into the picks? AVDI: I’ve got a quick question. CHUCK: Okay. AVDI: There’s a concern, probably a concern that I’ve heard a lot, that when somebody reads a book like that, whether its DDD or maybe the growing object oriented software book or really any of these books,  particularly books that has some kind of patterned language, that they will then go absolutely nuts. They’ll try to sort of pick a few pattern out of the book and then squeeze everything they see in those patterns and a lot of the pushback that I see against patterns and classical OO principles is based on bad experiences with somebody doing something like that or bad experience with the person themselves having made that mistake in the past. Do you have any advice about how to incorporate DDD principles into your life without falling into that? DAVID: I’d say.. JAMES: Drink the Cool-Aid. CHUCK: Just do it man. AVDI: Hmm cherry flavour. DAVID: I think there’s an awful desire when you read something especially at something as ambitious as DDD. I know I had when I read Martin Fowlers Patterns of Enterprise Application Architecture, I immediately started my own ORM but it was kind of, I would say, in a sandbox type environment. I was just doing it a spike at my own time. It’s a lot more freeing than having to do it when you’re under the gun and your accountable for delivery.  I think that spiking is a great... or kinda of doing like sheret or a little sketch on your own it’s a wonderful way to learn it, and to see hows it applied. I think there’s an awful desire to want to apply it, once you’ve got that merit badge and gotten through that book, right. I think yeah be pragmatic about where you apply it. I think it may be dangerous and damaging to your career if you applied it in the wrong place of your work. I also like think, take some of the small stuffs and see where you can apply it. Like with what Charles said is a really great approach. Be pragmatic and say, you know I can apply that notion of intention revealing interfaces to creating class methods of my ActiveRecord models. That’s a small step that maybe… and they will be a number of things in that book whether you can see how can I apply this to what I already have. I also kinda think, you know, I’m now 36, so I'm past the democratic of brand loyalty, and I'm kinda skeptical of everything, but I think kinda, just being... take that excitement. Definitely practice it, cause that’s how we become good at things, we practice them and do them a bunch of times. I mean we do sometimes fail and figure out where it doesn’t fit. So I think practice is a really important thing  but also “the bitter man rots within”. You don’t wanna be jaded and cranky and an old man about it, but I do kinda think take things with a grain of salt. Look at it and really evaluate. Is there something that I should be super excited about? JAMES: Is this giving me insights or is this process for process sake? DAVID: I’m getting all life coachy here, but, you know, I think you got to kinda put everything in its place. I think pragmatism is a very important skill and it’s a skill like anything else, you know, it’s something that you consciously bring to bear into situations. It’s not just that you read your pragmatic program now, you’re pragmatic. It’s a way of life that I think is pretty valuable or is a value, well valuable in software developments, kinda picking the right things, picking the right tool for the job. JAMES: Yeah, group hug everybody. DAVID: [laughs] I don’t know if that’s unsatisfying, but I think that there is going to be an intense desire to want to apply these patterns. I think Avdi, the way, kinda question read to me, you know, how do you avoid that pitfall and I think that just focus on some of the small things that you can apply to existing solutions, and then if you do really want to practice this thing, applying it, do it in side projects, personal projects where the risks is minimal. I think do sample application, go look for some sample application that kind thing. CHUCK: Okay sounds good. Did we warn you about some picks David? DAVID: Yeah I’m a listener so I’m aware. JAMES: Okay, good deal. James, why don’t you start us off for the picks. JAMES: Okay I don’t have anything big because I’ve been sick. I can’t talk for very long without having to mute so I can cough again. But I did do a speech last week on Math Literacy in the U.S. I now mention that I was gonna do it on Twitter and some people ask me if this slide is gonna be online and they’re online so if that kind of thing interests you I gave a talk to local atheist group so it does have some skepticism and stuff like that but I don’t think that’s very hardcore still if that kind of thing bothers, you might wanna skip it, but mostly it’s a look at where we are in Math and what kind of things that can we do to get better with Math that kind of thing. So look through those slides if that kind of thing interests you. CHUCK: Cool Avdi what are your picks? AVDI: So I had another of those “look around the desk and find something I haven’t picked yet” days and to my surprise, I have not pick this book yet. So one of my absolute most essential Ruby books is ‘The Ruby Way’ 2nd edition by Hal Fulton and  it comes off the shelf very, very regularly when I want to look up something obscure. Like yesterday, I was looking up more information about the Ruby standard conversion protocols. And it is just a great resource. For a non-coding pick, (I don’t I picked this before) there are these Twitter accounts that are basically, they are like live twitting World War II, so it’s just like shifted back in time you know a certain number of decades. And there’s one which is like real time World War II or something like that. (I’ll give the link of the show notes). There’s another one which is from a woman perspective whose on the home front called ‘RosiesWWII’ and just it’s fascinating stuff. CHUCK: Awesome. Yeah let’s make sure we get them in the show notes. I’ll  go ahead and jump in here next, so one pick that I’ve really been enjoying lately, it’s an application for the Mac, it’s in the mac app store it’s called ‘Daily Sudoku’. Just something that I’ve really have been if I just need to sit down and, you know, kind of unwind or I need to distract myself because I’m facing some decision that I don’t want to make and I don’t wanna burn up a ton of willpower trying to, you know, to make the right decision, and then I’ll actually just take a break and do a Sudoku or a crossword puzzle or something. Something that takes enough brain power to where I can’t focus on it and my problem at the same time and that’s  a good way to break things up. And the thing that I really like about beyond the fact that you just can play Sudoku on your machine, is that it has various difficulty levels and as you get in to the more difficult levels, then you can actually use their hints feature and the hints feature actually then will coach you through some more of the advanced Sudoku solving techniques. So, you get to the point where you don’t have any way of just solving it by just looking at rows and columns maybe using some of simpler techniques that are easy to identify. So I’ve been enjoying that and it actually links you to some Sudoku wiki that explains some of them, not very well in some cases, but it does explain them. The other pick that I have is Handlebars.JS and the thing that I like about Handlebars is that it does pretty much everything that I needed it to do. So, you can put something like really basic I guess, their block expression, is what they call them. It’s kind of a logicless templates, is the whole idea and so you just basically give it a binding and you render the template with that binding and it’ll call all of the different functions on the object that you put in there. I really, really like it. It’s written by Yehuda Katz and friends. Definitely worth checking out. David what are your picks? DAVID: Alright my first pick, I’ve got two that kinda go together; one's a developer and one’s not. The first one is Hammock Driven Development, which is a talk by Rich Hickey who invented Clojure. He’s the Clojure guy and this whole approach is you wanna prepare for kind of hard problem, state it, figure out what you know about it, figure out what you don’t know, etcera. And then get into Hammock and chill out and then let the inspiration come, you know, so the Hammock could be any kind of thing that chills you out. Just get away from it for a bit and then come back and evaluate. It’s his process for developing things, and I think it’s just a neat life hacky kind of thing. My second pick is an actual hammock. It’s the “Exped Ergo Hammock Combi”. I just got this. It’s a backpacking hammock, but you can use it in any kind of situation. If you’re like a gear nerd, you’ll love this thing. It's got a huge tarp, it uses a suspension bridge technology to suspend you at a 45 degree angles from the main line of the hammock that connects to trees. It's 3pounds super light and it gets you off the ground. I hate sleeping in the ground but I love backpacking, hiking, camping and stuff like that. So Hammock Driven Development and the Exped Ergo Hammock Combi for you Hammock Drive Development, in nature. JAMES: That’s insanely cool. DAVID: Yeah. It’s pretty fun. Pretty fun thing. CHUCK: Yeah that’s awesome. I just look at the picture cause you posted a link. it looks really comfortable too. DAVID: I wouldn’t say it’s good for, you know, I’m 5’10-5’11, so for big dudes that probably is gonna be a little short, but if you’re a medium size individual then I think it’s a great, great option. CHUCK: So it fits you pretty well? Is that what you are saying? DAVID: Yeah. CHUCK: I just didn’t know you thought of yourself as a big dude or something. DAVID: No, no, no. I’m medium size. CHUCK: Okay. Alright, a few announcements, if you haven’t signed up yet you can go to rubyrogues.com and sign up for Ruby Rogues Parlay, that’s our mailing list were we discuss the show and the upcoming episodes and stuff like that. Definitely worth it you can just donate $10/year and we’re just splitting that money up so it just goes to all the different Rogues. I also wanna thank our sponsors. The other thing I wanna bring is our Book Club, we are gonna be reading, “Growing Object Oriented Software Guided by Tests” and we’ll be talking to the author sometime in August. I’m still pinning that  down but it will be in August. Is there is anything else that I need to bring up before we wrap this up? All right. We’ll then we’ll go ahead and end the show we’ll catch you next week. Well,  maybe not next week. Next week is 4th of July, but if not next week then in two weeks. JAMES: Thanks, David. DAVID: Thanks for having me guys. It was a real pleasure. CHUCK: Yeah, it was fun. Really appreciate it.