Podcasts about domain driven design ddd

In dieser Podcast-Folge sprechen Martin und Florian mit Jörn Koch, Coach und Trainer für Domain-Driven Design (DDD) und agile Methoden bei der Workplace Solutions GmbH, über Scenario Casting. Diese kollaborative Methode hilft dabei, Softwareentwicklungsprojekte strukturiert zu gestalten. Sie wird von Fachexperten vorangetrieben und in Form von Szenarien ausgedrückt. Weitere Informationen unter: scenario-casting.org. Mehr über Jörn Koch: https://www.linkedin.com/in/joern-koch/ Kontakt und Feedback: www.systemischagil.com info@podcast-systemisch-agil.de Mehr über Martin: https://www.projektbuero15.de und Florian: https://www.storylines.hamburg Folgt uns auf Instagram: https://www.instagram.com/systemisch_agil/?hl=de und LinkedIn: https://www.linkedin.com/company/systemischagil/

Is the ultimate Domain-Driven Design (DDD) dream having a domain expert fully embedded in a Mob? Or does it come with hidden trade-offs? In this thought-provoking episode of the Mob Mentality Show, we explore the benefits, challenges, and real-world experiences of having a domain expert (or product owner) participate full-time in a Mob—not just as a consultant but as an active driver and navigator.

Le parcours erratique d'un CTO barbu

In this episode of the Mob Mentality Show, we explore the profound concept of "Chesterton's Fence" and how it applies to software development and organizational culture. Chesterton's Fence refers to the idea that before removing or changing a rule, tradition, or practice, one must first understand why it was put in place. We dive into this principle, discuss real-world coding examples, and contrast it with the famous "Five Monkeys Experiment," which explores how behavior and practices can irrationally persist even when the original purpose is forgotten.

 In today's episode, Charles, Steve, and AJ, are joined by back-end engineer and team lead at Homebound, Stephen Haberman. We delve into the fascinating world of SQL c and its revolutionary approach to managing SQL queries with dedicated SQL files, delivering benefits such as reduced typing errors and pre-deployment checks. Stephen also walks us through the advantages and limitations of ORMs versus query builders like Prisma and Drizzle, sharing insights into Joyce ORM's unique philosophy and simplified CRUD operations.They explore the intricacies of Domain Driven Design (DDD), its emphasis on ubiquitous language, and how it shapes business logic and storage management. AJ contributes by discussing the potential of SQL c and Slonik for dynamic query building. Additionally, they discuss Steven's innovative work with GraphFileWorker and GrafAST, highlighting the performance improvements in GraphQL backends. Whether you're intrigued by the technicalities of ORMs, the evolution of database tools, or just love a good anecdote, this episode packed with technical insights and lively discussions is one you won't want to miss. Join them on this journey into the world of database management and development!SocialsLinkedIn: Stephen HabermanPicks AJ - TypeScript to JSDocAJ - MySQL to TypeScriptAJ - sqlcAJ - Slonik (Node + Postgres)AJ - SwiftUI EssentialsAJ - Introduction to SwiftUI AJ - Trump, but not saying dumb thingsCharles - Biblios | Board GameCharles - FreeStyle Libre 3 System | Continuous Glucose MonitoringStephen - Grafast | GrafastBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Neste episódio, nosso hosto convidado CFC recebe Eduardo Matos e Felipe, dois especialistas em tecnologia, para uma conversa esclarecedora sobre Domain-Driven Design (DDD) e Team Topologies. Discutem sobre como essas abordagens podem ajudar a alinhar a comunicação entre negócios e engenharia, melhorar a eficiência e enfrentar os desafios organizacionais. Com exemplos práticos do setor financeiro, nossos convidados compartilham insights valiosos sobre como implementar essas práticas de forma eficaz e evitar armadilhas comuns. Junte-se a nós para entender como essas estratégias podem transformar sua equipe e seu negócio!

Die Umsetzung von taktischem Domain-Driven Design (DDD) in Java birgt einige technische Herausforderungen. In dieser Episode betrachten wir einen Ansatz, der Entwickler:innen dabei unterstützen reichhaltige Domänenmodelle in Java zu implementieren: die jMolecules Bibliothek ermöglicht es, DDD Konzepte direkt in Code auszudrücken und bietet darüber hinaus Integration in weitverbreitete Technologien wie Spring, Jackson und Persistenztechnologien. Oliver Drotbohm ist Engineer bei Broadcom und einer der Entwickler von jMolecules. Links Olivers Demo bei GitHub Taktisches Domain-driven Design Architektur-Hamburger mit Henning Schwentner Vaughn Vernon about Ports and Adapters and DDD Markus Völter zu Fachliche Architekturen mit DSL (Domain Specific Languages) Peter Gafert zu ArchUnit Dirk Mahler zu Software-Architektur-Management mit jQAssistant

Mark Wardle, Chief Clinical Information Officer, and Vaughn Vernon discuss the intersection of healthcare and technology. Mark emphasizes the need for technology to improve patient care and the challenges of integrating digital systems in healthcare.Mark also highlights the importance of Domain-Driven Design in healthcare, as it allows for a more patient-centered approach and better communication between clinicians and patients. He discusses the limitations of current electronic health records and the need for tools that support continuity of care. Mark believes that technology should be used to enhance the human connection in healthcare and improve patient outcomes.Mark discusses the application of Domain-Driven Design (DDD) in healthcare and its potential to address the complexity and challenges in the industry. He emphasizes the need to break down healthcare systems into modular components and build them based on a shared understanding of the domain. Wardle highlights the importance of technical standards, interoperability, and the use of common models to decouple systems and improve integration. He also discusses the role of open source in healthcare and the potential for disruptive innovation. Wardle envisions a future where technology enables faster iteration, better orchestration of clinical pathways, and improved decision-making in healthcare.TakeawaysTechnology has the potential to greatly improve patient care in healthcare.DDD is crucial in healthcare to create a patient-centered approach and improve communication between clinicians and patients.Current electronic health records are often not user-friendly and do not support continuity of care.Technology should be used to enhance the human connection in healthcare and improve patient outcomes. Domain-Driven Design can help address the complexity and challenges in healthcare by breaking down systems into modular components and building them based on a shared understanding of the domain.Technical standards and interoperability are crucial for decoupling systems and improving integration in healthcare.Open source has the potential to disrupt the healthcare industry by providing foundational building blocks and higher-value tools.Improving orchestration of clinical pathways and decision-making in healthcare can be achieved through the use of technology and data-driven approaches.Faster iteration, better integration, and improved decision-making can lead to a learning health and care system that continuously improves patient outcomes.Mark WardleMark is a Consultant Neurologist and Chief Clinical Information Officer in the UK. He is also a keen software developer, building a range of clinician and patient-facing applications, most recently preferring to work in Clojure and ClojureScript. He thinks digital technologies should play a fundamental role in improving and transforming health and care with Domain-Driven Design playing a key role in unbundling the electronic patient record, and turning what we think of as health applications inside-out. Hosted on Acast. See acast.com/privacy for more information.

Domain-driven Design (DDD) bietet einen umfangreichen Werkzeug-Kasten. Aber bei Architektur-Diskussionen kommt die Code-Ebene oft zu kurz, obwohl DDD auch in dem Bereich helfen kann. Im Mittelpunkt dieser Episode soll daher das sogenannte taktisches Design stehen. Diese Patterns beschreiben, wie man Geschäftslogik in einem objekt-orientierten System aufbauen kann. Dazu gehören Ideen wie Entity, Aggregate oder Service. Links Sketchnotes Softwarearchitektur-Kickstart Martin Fowler: Pattern of Enterprise Application Architecture Transaction Script Table Module Eric Evans: DDD Referenz Folge zu Events, Event Sourcing und CQRS Folge mit Susanne Braun zu Eventual Consistency DDD Crew: Event Storming Glossary Cheat Sheet Alberto Brandolini: Introducing Event Storming SoftwareArchitekTOUR-Podcast zu taktischem Design

Andrzej Krzywda discusses event sourcing, event-driven architecture, and Domain-Driven Design (DDD) in the context of Ruby on Rails applications. He explains the concept of bounded contexts and how they relate to communication between different modules. He also shares insights on when and why to apply DDD to Rails applications, particularly in cases where the application becomes complex and difficult to maintain. Andrzej explores the challenges and benefits of migrating an existing Rails app to an event-driven architecture and highlights advanced event sourcing concepts such as snapshotting, projections, and versioning. In this conversation, Andrzej Krzywda discusses event sourcing and DDD in Rails applications. He explains the concepts of snapshotting and projection, which are techniques used to optimize performance and retrieve specific data from event streams. Andrzej also delves into the challenges of event versioning and how it can be managed in Rails applications. Additionally, he shares insights about the wroclove.rb conference, its history, and its focus on advanced and deep technical topics.TakeawaysEvent sourcing is a persistence mechanism that persists all the little changes that happen to a specific object, while event-driven architecture is a way of building software modules that communicate with events.DDD involves splitting a system into contexts or domains and using events to communicate between them. It can be applied to Ruby on Rails applications, particularly in cases where the application becomes complex and difficult to maintain.Migrating an existing Rails app to an event-driven architecture can help address issues with large classes, complex associations, and lack of modularity.Advanced event sourcing concepts such as snapshotting, projections, and versioning can be used to optimize performance and manage data integrity in event-driven applications. Snapshotting and projection are techniques used in event sourcing to optimize performance and retrieve specific data from event streams.Event versioning is a challenge in event sourcing, but it can be managed by introducing new event versions and implementing upcasters to convert old events to new versions.wroclove.rb is a Ruby and Rails conference in Wrocław, Poland, that focuses on advanced and deep technical topics.The conference aims to inspire, educate, and challenge the status quo in the Ruby and Rails community.Rails Event Store and Eventide are two libraries that facilitate the implementation of event-driven architectures in Rails applications, each with its own philosophy and approach.wcrolove.rb Ruby and Rails ConferenceRailsEventStoreArkencyRails Architect Masterclass[Video] Event Sourcing Demystified: A Simple-To-Understand Guide

Dive into the world of zero bugs and lean mobbing with David Batten on this episode of Mob Mentality Show. Discover the distinction between the scary and healthy versions of zero bugs, and explore how David and his teams achieved a bug-free environment. Uncover insights on when to shift focus away from zero bugs, anti-patterns to avoid, and the art of baking quality into your code.  Explore the synergy of Lean principles, Continuous Delivery (CD), and Test Driven Development (TDD) as David shares how they got to zero bugs as a natural side effect. Learn about the application of the prime directive to foster continuous improvement and the joy of being in a bug-free system.  Explore the facet of Lean where we draw systems and seek ways to shorten feedback loops. Gain insights into the business perspective on Lean and the power of tiny commits. Understand the role of Lean in risk conversion, frequency, and Domain Driven Design (DDD) for organizational simplicity. Join us in exploring the art of mobbing as David recounts his first mobbing experience to meet a deadline and shares his 9 years of mobbing wisdom. Learn how having the entire system in the room ensures that when it's done, it's truly done. David also discusses the impact of mobbing on CD, the benefits of bringing the best of everyone into the code, and a sneak peek into the April 2024 Teaming Conference. If you're passionate about #mobprogramming, #bugszero, #continuousdelivery, #tdd, #leanthinking, #xp, this episode is a must-listen. Elevate your coding mindset and join the conversation on achieving zero bugs naturally through lean mobbing! Video and Show Notes: https://youtu.be/8-EL9x89Ag0 

In this episode of the Add Dot podcast, Vaughn Vernon and Paul Rayner discuss the evolution of the Domain-Driven Design (DDD) community in North America. The conversation highlights the importance of fostering connections and providing valuable learning experiences.Throughout the conversation, Vaughn and Paul share insights into the complexities of modernization efforts, particularly in large organizations with legacy systems. They stress the importance of strategic thinking, focusing on core domains, and avoiding the "boil the ocean" approach. The episode concludes with a teaser for the upcoming Explore DDD conference in Denver, Colorado, scheduled for March 12-15, 2024, featuring keynotes by Eric Evans and Vaughn Vernon.Paul Rayner is a developer, instructor, coach, consultant, and popular conference speaker with over thirty years of software development experience. Paul provides DDD and EventStorming training and coaching through Virtual Genius.Paul is the founder and chair of the Explore DDD conference, the premier Domain-Driven Design conference in North America, and co-founder of DDD Denver. He is also the author of The EventStorming Handbook, and a co-author of Behavior-Driven Development with Cucumber. He lives in Denver, Colorado. Hosted on Acast. See acast.com/privacy for more information.

Joël shares he has been getting more into long-form reading. Stephanie talks about the challenges she faced in a new project that required integrating with another company's system. Together, they delve into the importance of search techniques for developers, covering various approaches to finding information online. Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) Episode on heuristics (https://www.bikeshed.fm/398) Episode on specialized vocabulary (https://www.bikeshed.fm/356) Episode on discrete math (https://www.bikeshed.fm/374) Joël's discrete math talk at RailsConf (https://www.youtube.com/watch?v=wzYYT40T8G8) Dash (https://kapeli.com/dash) Alfred (https://www.alfredapp.com/) Indiana Jones and the Crypt of Cryptic Error Messages (https://thoughtbot.com/blog/indiana-jones-and-the-crypt-of-cryptic-error-messages) Browser History confessional by Kevin Murphy (https://www.youtube.com/watch?v=R7LkHjJdH9o) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: Something I've been trying to do recently is get more into long-form reading. I read quite a bit of technical content, but most of it are short articles, blog posts, that kind of thing. And I've not read, like, an actual software-related book in a few years, or at least not completed a software-related book. I've started a few chapters in a few. So, something I've been trying to do recently is set aside some time. It's on my calendar. Every week, I've got an hour sit down, read a long-form book, and take notes. STEPHANIE: That's really cool. I actually really enjoy reading technical stuff in a long-form format. In fact, I was similarly kind of trying to do it, you know, once a week, spend a little bit of time in the mornings. And what was really nice about that is, especially if I had, like, a physical copy of the book, I could close my computer and just be completely focused on the content itself. I also love blog posts and articles. We are always talking on the show about, you know, stuff we've read on the internet. But I think there's something very comprehensive, and you can dig really deep and get a very deeper understanding of a topic through a book that kind of has that continuity. JOËL: Right. You can build up a larger idea have more depth. A larger idea can also cover more breadth. A good blog post, typically, is very focused on a single thing, the kind of thing that would really probably only be a single chapter in a book. STEPHANIE: Has your note-taking system differed when you're applying it to something longer than just an article? JOËL: So, what I try to do when I'm reading is I have just one giant note for the whole book. And I'm not trying to capture elements or, like, summarize a chapter necessarily. Instead, I'm trying to capture connections that I make. So, if there's a concept or an argument that reminds me of something perhaps similar in a different domain or a similar argument that I saw made by someone else in a different place, I'll capture notes on that. Or maybe it reminds me of a diagram that I drew the other day or of some work I did on a client six months ago. And so, it's capturing all those connections is what I'm trying to do in my notes. And then, later on, I can kind of go back and synthesize those and say, okay, is there anything interesting here that I might want to pull out as an actual kind of idea note in my larger note-taking system? STEPHANIE: Cool, yeah. I also do a similar thing where I have one big note for the whole book. And when I was doing this, I was even trying to summarize each chapter if I could or at least like jot down some takeaways or some insights or lines that I like felt were really compelling to me. And, like, something I would want to, in some ways, like, have created some, like, marker for me to remember, oh, I really liked something in this chapter. And then, from there, if I didn't capture the whole idea in my note, I knew where I could go to revisit the content. JOËL: And did you find that was helpful for you when you came back to the book? STEPHANIE: Yeah, it did. I usually can recall how, like, I felt reading something. You know, if something was really inspiring to me or really relatable, I can recall that, like, I had that experience or emotion. And it's just, like, trying to find where that was and that this is a system that has worked well for me. Though, I will say that summarizing each chapter did kind of remind me of, like, how we learned how to take notes in school. [laughs] And I think, you know, middle school, or whatever, I recall a particular note-taking format, where you, you know, split the page up into, like, an outline with all the chapters, and you tried to summarize it. And so, it did feel a little bit like homework [laughs]. But I can also see the value in why they taught me how to do that. JOËL: I was recently having a conversation with someone else about the idea of almost, like, assigning yourself the college-style essay question after finishing a book to try to synthesize what you learned. STEPHANIE: Whoa, that's really cool. I can see how that would really, like, push you to synthesize and process what you might have just consumed. And, also, I'm so glad I'm not in school anymore [laughs] so that I don't have to do that on a regular basis. [laughs] I'm curious, Joël, what book are you reading right now? JOËL: I've been reading Domain Modeling Made Functional, which is a really interesting intersection between functional programming, Domain-Driven Design (DDD), and a lot of interesting kind of type theory. And so, that sort of intersection of those three Venn diagrams leads to this really fascinating book that I've been going through. And I think it connects with a lot of other things that I've been thinking about. So, I'll be reading and be like, oh, this reminds me of this concept that we have in test-driven development. Or this reminds me of this idea that we do when we do a product design sprint. And this reminds me of this principle from object-oriented design. And now I'm starting to make all these really interesting connections. STEPHANIE: Awesome. Well, I hope to hear more about what you've learned or kind of what you're thinking about going through this book in future episodes. JOËL: This is not the last time we hear about this book, I'm pretty sure. So, Stephanie, what's new in your world? STEPHANIE: So, I have a little bit of a work update to share. So, lately, I've been brought in to work on a feature that is integrating with another company's system. And the way that I was brought into this work was honestly just being assigned a task. And I was picking up this work, and I was kind of going through the requirements that had been specked out for me, and I was trying to get started. And then, I realized that I actually had a lot of questions. It just wasn't quite fully fleshed out for the level of detail that I needed for implementing. And for the past couple of weeks, we've been chatting in Slack back and forth as I tried to get some of my questions answered. They are trying to help me, but also the things that I'm saying end up confusing them as well. And then, I end up having to try and figure out what they're looking for in order to properly respond to them. And I had not met these people before. These are folks from that other company. And, you know, I'd only just seen their little Slack profile pictures. So, I didn't know who they were. I didn't know what role they had and kind of, like, what perspective they were coming to these conversations from. And after a while, I was feeling a little stressed out because we just kept having this back and forth, and not a lot of answers were coming to fruition. And I really ended up needing the nudge of the manager on my client team to set up a meeting for us to all just talk synchronously. And I think I had...not that I had been avoiding it necessarily, but I guess I was under the impression that we were at the point where we could just, you know, shoot off a question in Slack and that there would be a clear path forward. But the more we kept pulling on that thread, the more I realized that, oh, like, we have a lot of ambiguity here. And it really helped to meet them finally, not in person but, like, over a video call. [laughs] So, this happened yesterday. And, you know, even just, like, going around doing introductions, like, sharing what their role was at the company helped me just understand, like, who I was talking to. You know, I realized, oh, like, the level of technical details that I had been providing was maybe too much for this group. And I was able to have a better understanding of what their needs were, like hearing kind of the problem that they had on their end. And I realized that, oh, like, they actually aren't going to provide me the details for implementation that I was looking for. That's up to me. But at least now I know what their higher-level needs are so that I can make the most informed decisions that I can. JOËL: Fascinating. So, you thought that this was going to be, like, the technical team you're going to work with. And it turns out that this was not who they were. STEPHANIE: In some ways. I think I thought by providing more technical details that would be helpful, but it ended up being more confusing for them. And I think I was similarly kind of frustrated because the ways that I was asking questions or communicating also wasn't getting me the answers that I needed as well. But I felt really great after the meeting because I'm like, wow, you know, it doesn't have to be as stressful. You know, when you start getting into that back and forth on Slack, at least I find it a bit stressful. And it turns out that the antidote to that was just getting together and getting to know each other and hashing out the ambiguity, which does seem to work better in a more synchronous format. JOËL: Do you have kind of a preference for synchronous versus asynchronous when it comes to communication? STEPHANIE: That's a good question. I think it's kind of a pendulum for me. I'm in my asynchronous communication is a bit better for me right now phase, but only because I am just so burnt out on meetings a lot of the time that I'm like, oh, like, I really don't want to add another meeting to my calendar, especially because...I amend my statement; I'm burned out of meetings that don't go well. [laughs] And this meeting, in particular, was different because, you know, I realized, like, oh, like, we are not on the same page, and so how can we get there? And kind of making sure that we were focused on that as an agenda. And I found that ultimately worked out better than the async situation that I was describing, which I'm thinking now, you know when things aren't clear, text-based communication certainly does not help with that. JOËL: So, meetings, sometimes they're actually good. STEPHANIE: Yeah, that's my enlightened discovery this week. JOËL: So, this episode is kind of a special one. We've just hit 400 episodes of The Bike Shed. So, this is episode number 400. It's also my 50th Episode as a co-host. STEPHANIE: Right. That's a huge deal. 400 is a really big number. I don't know if I've ever done 400 of anything before [laughs]. JOËL: The Bike Shed has been going on for almost ten years now. The first episode up on the website is from October 31st, 2014, so just about nine years from that first episode. STEPHANIE: Wow. And it's still going strong. That's really awesome. I think it's really special to be a part of something that has been going on for this long. And, I don't know, maybe there are still listeners today from back in 2014. I would be really excited to hear if anyone out there has been listening to The Bike Shed throughout its whole lifespan. That's really cool. JOËL: Looking back over the last 50-ish episodes you and I have done, do you have a favorite episode that we've recorded? STEPHANIE: This may be a bit of recency bias. But the episode that we did about Software Heuristics I really enjoyed. Because I think we got to bring to the table some of the things we believe and the way we like to do things and kind of compare and contrast that with each other. And I always find people's processes very fascinating. Like, I want to know how you think and where your brain is at when you approach a problem. So, I really enjoyed that topic. What about you? Do you have any highlight episodes? JOËL: I think there's probably two for me. One is the episode that you and I did on Specialized Vocabulary. I think this really touched on a lot of really interesting aspects of writing software that's going to scale, software that works for a team, and also kind of personal growth and exploration. The second one that I think was really fun was the episode I did with Sara Jackson as a guest talking about Discrete Math because that's an episode that I got really excited about the topic. And right after recording the episode, it was the last day of the call for proposals for RailsConf. And I just took that raw excitement, put together a proposal, hit submit before the deadline. And it got accepted and got turned into a talk that I got to give on stage. So, that was, like, just a really fun journey from exciting episode with Sara and then, like, randomly turned into a conference talk. STEPHANIE: That's awesome. That makes me feel so happy. Because it just reminds me about how the stuff we talk about on the show can really resonate with people, you know, enough to become a conference talk that people want to attend. And I also really like that a lot of the topics we've gotten into in the past 50 episodes when we've taken over the show have been a bit more evergreen and just about, you know, the software development experience and a little bit less tied to specific news within the community. Speaking of evergreen topics, today, I wanted to discuss with you an evergreen software skill, and that is searching or Search-Driven Development, even if you will. JOËL: Gotta always get that three-letter acronym, something DD. STEPHANIE: Yeah. I am really curious about how we're going to approach this topic because a lot of folks might joke that a big part of writing software is knowing what to Google. Do you agree with that statement or not? JOËL: Yes and no. There's definitely value in knowing what to Google. It really depends on the kind of work that you're doing. I find that I don't Google that much these days. There are other tools that I use when I'm particularly, like, searching through documentation, but they tend to be less sort of open-ended questions and more where it's like, oh, let's get the actual documentation for this particular class or this particular method from the standard library. STEPHANIE: Oh, interesting. I like that you pointed out that there are different scopes of things you might want to search for. So, am I hearing correctly that when you have something specific in mind that you are just trying to recall or wanting to look up, you know, you're still using search that way, but less so if you are trying to figure out how to approach solving a problem? JOËL: So, oftentimes, if I'm working with a language that I already have familiarity with or a framework that I have familiarity with, I'm going to lean on something more specific. So, I'm going to say, okay, well, I don't exactly remember, like, the argument order for Enumerable's inject method. Is it memo then item, or item then memo? So, I'll just look it up. But I know that the inject method exists. I know what it does. I just don't remember the exact specifics of how to do that. Or maybe I want to write a file to disk, and I don't remember the exact method or syntax to do that. There are some ways that you can do it using a bunch of instance methods. But I think there's also a class method that allows you to kind of do it all at once. So, maybe I just want to look up the documentation for the file class in Ruby and read through that a little bit. That's the kind of thing where I suppose I could also Google, you know, how to save file Ruby, something like that. But for those sorts of things where I already roughly know what I want to do, I find it's often easier just to go directly to the docs. STEPHANIE: Yeah, yeah, that's a great tip. And I actually have a little shortcut to share. I started using DuckDuckGo as my search engine in the past year or so. And there's this really cool feature called Bangs for directly searching on specific sites. From my search bar, I can do, let's say, bang Rails and then my query. And it will search directly the Rails Guides website for me instead of, you know, just showing the normal other results that might come up in my regular search engine. And the same goes for bang Ruby doc. That one shows ruby-doc.org, which is my preferred [laughs] Ruby documentation website. I've really been enjoying it because, you know, it just takes that extra step out of having to either navigate to the site itself first or starting more broadly with my search engine and then just scrolling to find the site that I'm looking for. JOËL: Yeah. I think having some kind of dedicated flow helps a lot. I have a system that I use on my machine. It is Mac-specific. But I use a combination of the application Dash and the application Alfred. It allows me, with just a few keyboard shortcuts, to type out language names. So, I might say, you know, Ruby inject, and then it'll show me all the classes that have that method defined on it, hit Enter, and it pops up the documentation. It's downloaded on my machine, so it works offline. And it's just, you know, a few key presses. And that works really nicely for me. STEPHANIE: Oh, offline search. That's really nice. Because then if you're coding on a plane or something, then [laughs] you don't have to be blocked because you can't look up that little, small piece of information you need to move forward. That's very cool. JOËL: That is really cool. I don't know how often I've really leaned into the offline part of it. I don't know about you; I feel like I don't code on airplanes as much as I thought I would. STEPHANIE: That's fair. I also don't code on airplanes, but the idea that I could is very compelling to me. [laughs] JOËL: Absolutely. So, that's the kind of searches that I tend to do when I'm working in a language that I already know, kind of a day-to-day language that I'm using, or a framework that I'm already pretty familiar with. And this is just looking at all the things I haven't gotten to the point where I've fully memorized, but I have a good understanding of. What about situations where maybe you're a little bit less familiar with? So maybe it's a new framework, or even, like, a situation where you're not really sure how to proceed. How do you search when there's more uncertainty? STEPHANIE: Yeah, that's a good question. I do think I start a bit naively. The reason that we're able to be more specific and know exactly where to go is because we've built up this experience over time of scrolling through search results and clicking, you know, maybe all of them on the first page, even, and looking at them and being like, oh, like, this is not what I want. And then, seeing something else, it's like, oh, this is more helpful and kind of arrived at sources that we trust. And so, if it's something new, I don't really mind just going for a basic search, right? And starting more broadly might even be helpful in that process of building up the experience to figure out which places are reputable for the thing that I'm trying to figure out. JOËL: Yeah, especially when there's a whole new landscape, right? You don't really know what are the places that have good information and the ones that don't. For some things, there might be, like, an obvious first place to start. So, recently, I was on a project where I was trying to do an integration between a Rails app and a Snowflake data warehouse. And so, the first thing I did—I'm not randomly Googling—I went to the Snowflake website, their developer portal, and started reading through documentation for things. Unfortunately, a lot of the documentation is a bit more corporatey and not really helpful for Ruby-specific implementation. So, there's a few pieces that were useful. There were some links that they had that sent me to some good places. But beyond that, I did have to drop to Google search and try to find out what kinds of other things the community had done that could be helpful. Now, that first pass, though, did teach me some interesting things. It gave me some good keywords to search for. So, more than just Ruby plus Snowflake or something like that like, I knew that I likely was going to want to do some kind of connection via ODBC. So, now I could say, okay, Ruby plus ODBC integration, or Ruby plus ODBC driver and see what's happening there. And it turns out that one of the really common use cases for ODBC and Ruby is specifically to talk to Snowflake. And one of the top results was an article saying, "Hey, here's how you can use ODBC to get your Rails app to talk to Rails." And then I knew I struck gold. STEPHANIE: That's really cool. The thing that I was picking up on in what you were saying is the idea of finding what is most relevant to you. And maybe that is something that the algorithm serves you because, like, it's, like, what a lot of people are searching for, you know, a lot of people are engaging with, or matching with all these keywords that you're using. My little hack that I've been [chuckles] using is to use Slack and lean on other people who have maybe a little more, even just, like, a little more experience than me on the subject, and seeing, like, what things they're linking to, and what resources they're sharing. And I've found that to be really helpful as a place to start. Because, at that point like, my co-workers are narrowing down the really broad landscape for me. JOËL: I really like how you're sort of you're redefining the question a little bit here. And that, I think, when we talk about search, there's almost this implicit assumption that search is going to be searching the public internet through Google or some other alternative search engine. But you're talking about actually searching from my private corpus of data, in this case, either thoughtbot or maybe the client's Slack conversations, and pulling up information there that might be much more relevant or much more specific to the work that you're trying to do. STEPHANIE: Yeah. In some ways, I like to think of it as crowd-sourced but, like, a crowd that I trust and, you know, know is relevant to me and what I'm working on. I actually have a fun fact for you. Did you know that Slack is actually an acronym? JOËL: No, I did not know that. What does it stand for? STEPHANIE: It stands for Searchable Log of All Communication and Knowledge. JOËL: That is incredibly clever. I wonder, is this the thing where they came up with that when they made the original name? Or did someone go back later on, you know, a few years into Slack's life and was like, you know what? Our name could be a cool acronym; here's an idea. STEPHANIE: I'm pretty sure it was created in Slack's early days. And I think it might have even helped decide that Slack was going to be called Slack as opposed to some of the other contenders for the name of the software. But I think it's very accurate. And that could just be how I use Slack. I'm a very heavy search power user in Slack. [laughs]. So, I find it very apt. You know, obviously, I use it a lot for finding conversations that happened. But I really do enjoy it as a source of discovery for a specific topic, or, you know, technical question or idea that I'm wanting to just, like, filter down a little bit beyond, like you said, the public internet. In fact, I have found it really useful for when you encounter errors that actually are specific to your domain or your app. Obviously like, you will probably be less successful searching in your search engine for that because it includes, you know, context from your app that other people in the world don't have. But once you are narrowing it down to people at your company, I've been able to get over a lot of troubleshooting humps that way by searching in Slack because likely someone within my team has encountered it before. JOËL: So, you mentioned searching for error messages in particular. And I feel like that is, like, its own, like, very specific searching skill separate from more general, like, how do I X-style questions. Does that distinction kind of line up with your mental map of the searching landscape? STEPHANIE: Yeah. I guess the way that I just talked about it now was potentially a bit confusing because I was saying instead of how you might search for errors normally, but I did not talk about how you might search for errors normally. [laughs] But specifically, you know, if I'm popping error messages into my search engine, I am removing the parts of the stack trace that are specific to my app, right? Because I know that that will only kind of, like, clutter up my query and not be getting me towards a more helpful answer as to the source of my issue, especially if the issue is not my application code. JOËL: Right. I want to give a shout-out to an article on the thoughtbot Blog with a wonderful name: Indiana Jones and the Crypt of Cryptic Error Messages by Louis Antonopoulos. All about how to take an error message that you get from some process in your console and how to make that give you results when you paste it into a search engine. STEPHANIE: I love that name. Very cool. JOËL: So, you've talked a little bit about the idea of searching some things that are not on the public internet. How do you feel about kind of internet knowledge bases, private wikis, that kind of thing? Have you had good success searching through those kinds of things? STEPHANIE: Hmm, I would say mixed success, to be honest. But that's because of maybe more so the way that a team or a company documents information. The reason I say mixed results is because, a lot of the time, the results are outdated, and they're no longer relevant to me. And it doesn't take that much time to pass for something to become outdated, right? Because, like, the code is always changing. And if, you know, someone didn't go and update the documentation about the way that a system has changed, then I usually have to take the stuff that I'm kind of seeing in private wikis with a bit more skepticism, I would say. JOËL: Yeah, I think my experience mirrors yours as well. Also, some private wikis have just become absolutely huge. And so, searches just return a lot of results that are not really relevant to what I'm searching for. The searching algorithms that these systems use are often much less powerful than something like Google. So, they often don't sort results in a way that are bringing relevant things up to the top. So, it's more work to kind of sift through all of the things I don't care about. STEPHANIE: Yeah, bringing up the size of a wiki and, like, all of the pages, that is a good point because I see a lot of duplicate stuff, but that's just, like, slightly different. So, I'm not sure which one I'm supposed to believe. One really funny encounter that I had with a private wiki, or actually it was, like, a knowledge base article that was for the internal team...it was documenting actually a code process. So, it was documenting in more human-readable terms, like the steps an algorithm took to determine some result. But the whole document was prefaced by, "This information came from an email that was sent way long ago." [laughs] JOËL: That's an epic start to a Wiki article. STEPHANIE: Yeah. And there was another really funny line that said, "The reason for this logic is because of a decision made by (This person's name.)," like a business decision that (some random person name). No last name either, so I have no idea [laughs] who they could be referring to and any of the, like, historical context of why that happened. But I thought it was really funny as just a piece of, like, an artifact, of, at the time, when this was written, that meant something to someone, and that knowledge kind of has been diluted [laughs] over the years. JOËL: Yeah, internal wikis, I feel like, are full of that, especially if they've had a few years to grow and the company has changed and evolved. So, now it's time for hot takes. STEPHANIE: Yeah, I'm ready for them. JOËL: We are now in the fancy, new age of AI. Is ChatGPT going to make all of this episode obsolete? STEPHANIE: I'm going to say no, but I'm also biased, and I'm not a ChatGPT enthusiast. I've said it on air. [laughs] I can't even say that I've used it. So, that's kind of where I'm coming from with all this. But I have heard from folks that, convenient as it may be, it is not always 100% accurate or successful. And I think that one of the things I really like about kind of having agency over my search is that I can verify, as a human, the information that I'm seeing. So, you know, when you're, like, browsing a bunch of Stack Overflow questions and you see, you know, all these answers, at least you can, like, do a little bit of, like, investigation using context clues about who is answering the question, you know, like, what experience might they have? If you encounter something on a blog post, for example, you can go to the about page on this person's blog and be like, who are you? [chuckles] And, like, what qualifies you to give this information? And I think that is really valuable for me in terms of evaluating whether I want to go down a path based on what I'm seeing. JOËL: So, I've played with it a tiny, little bit, so not enough to have a good sample size. And I think it can be interesting for some of those less constrained kind of how do I style questions. I'm not necessarily looking for, like, an exact code sample. But even if it just points me towards, oh, I need to be looking at this particular class in this standard library and read through that documentation to build the thing that I want. Or maybe it links me to kind of the classic blog posts that people refer to when talking about this thing. It's a good way sometimes to just narrow down when you're kind of faced with, you know, the infinity of the internet, and you're kind of like, oh, I don't even know where to start. It gives you some keywords or some threads to follow up on that I think can be really interesting. STEPHANIE: The infinity of the internet. I love that phrase. I don't think I've heard it before, but it's very evocative for me [laughs]. And I like what you said about it helping you give a direction and to kind of surface those keywords. In fact, it almost kind of sounds like what I was mentioning earlier about using Slack for, right? And, in that case, the hive mind that I'm pulling from is my co-workers. But also, I can see how powerful it would be to leverage a tool that is guiding you based on the software community at large. JOËL: Something I'd be curious to maybe lean into a little bit more are some of those slightly more specified questions where it does give you a code snippet, so something like writing a file to disk where, right now, it's, you know, five characters. I just pop up Alfred and type up Ruby F, and it gives you the file docs, and it's, you know, right there. There's usually an example at the top of the file. I copy-paste that and get working. But maybe this would be a situation where some AI-assisted tools would be better. It could be searching through something like ChatGPT. It could be maybe even something like Co-pilot, where, you know, you just start typing a little bit, and it just fills out that skeleton of, like, oh, you want to write a file to disk in Ruby. Here's how it's typically done. STEPHANIE: Yeah, you bring up a good point that, in some ways, even the approaches to searching we were talking about originally is still just building off of algorithms helping us to find what we're looking for, right? Though, I did really want to recommend an awesome talk from Kevin Murphy, from a RailsConf a couple of years ago, that's called Browser History Confessional: Searching My Recent Searches. The main message that I really enjoyed from this talk was the idea of thinking about what you're searching for and why because that will, I think, help add a bit of, like, intentionality into that process. You know, it can be very overwhelming, but let that guide you a little bit. One of the things that he mentions is the idea of revisiting your own assumptions with search. So, even if you think you know how to do something, or you might even know, like, how you might want to do it, just going to search to see if there's any other implementations that you haven't thought of that other people are doing that might inform how you approach a problem, or at least, like, make you feel even more confident about your original approach in the first place. I thought that was really cool. That's not something that I do now, but definitely, something that I want to try is to be, like, I think I know how to do this, but let me see what other people are doing because that might spark something new. JOËL: We'll put a link in the show notes to this talk. But I was lucky enough to see it in person. And also would like to second that recommendation. It is worth watching. From this conversation that you and I have had, I'm having, like, two main takeaways. One is kind of what you just said, the idea of being a little bit more cognizant of, what kind of search am I doing? Is this a sort of broad how do I X, where I don't even really know where to start? Is this, like, something really specific where you just don't know what kind of syntax you want to use? Is it an error message where you just want to see what other people have done when they've encountered this? Or any other, like, more specific subcategories. And how being aware of that can help you search more effectively. And secondly, don't limit yourself to the public internet. There's a lot of great information in your company's Slack or other instant messaging service, maybe some kind of documentation system internal, some kind of wiki. And those can be a great place to search as well. STEPHANIE: If we missed any other cool searching tips or tricks or ways that we might be able to improve our processes for searching as developers, I would really love to hear about them. So, if any listeners out there want to write in with their thoughts, that would be super awesome. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

فهاد الحلقة غندويو على Domain driven-design (DDD) شنو هو ولاش كيصلاح واشنو الفرق بين Hexagonal architecture و Clean architectue ..

Was hat Event Storming mit dem Bullshit-Asymmetrie-Prinzip (auch bekannt als "Brandolinis Gesetz") zu tun? Diese und noch viel wichtigere Fragen, besprechen wir in dieser Podcast-Folge mit Jürgen Meurer. Event Storming ist eine Praktik, die ursprünglich aus dem Domain Driven Design (DDD) stammt. Die Erfindung der Methode wird Alberto Brandolini zugeschrieben. Ja genau - der mit dem gleichnamigen Gesetz: „Das Widerlegen von Schwachsinn erfordert eine Größenordnung mehr an Energie als dessen Produktion.“ Zurück zum Thema: Event Storming ist ein (Groß)Gruppenformat, um das verteilte Wissen über eine fachlich-technische Domäne in einem Workshop explizit zu machen und so ein "gemeinsam geteiltes mentales Modell" zu entwickeln. Kurz: alle die dabei waren kapieren den Gesamtzusammenhang der Fragestellung plötzlich viel besser. Gerade im Kontext komplexer Produktentwicklung eignet sich diese Methode somit sehr gut, ein gemeinsames Verständnis zu schaffen. Sie kann damit eine tolle Grundlage für Story Mapping oder Customer Journey Mapping bieten - aber auch für die Erstellung klassischer Projekt Strukturpläne. Du kannst Event Storming sowohl für bestehende Produkte anwenden, als auch in der Entwicklung komplett neuer Produkte und Services einsetzen. Jürgen Meurer, setzt diese Methode bereits seit vielen Jahren erfolgreich bei seinen verschiedenen Arbeitgebern an. Inzwischen ist Jürgen als Agile Coach aktiv, hat aber auch lange als Product Owner und Scrum Master gearbeitet. Damit ist er übrigens auch ein interessantes Beispiel für den Weg, sich vom Product Owner zum Scrum Master bzw. Agile Coach zu entwickeln. Seine letzten Stationen waren Studitemps, Freeyou, AXA und nun SHOP APOTHEKE bzw. Redcare Pharmacy. **Quellen und Links zum Event Storming** Jürgen Meurer empfiehlt die folgenden Quellen, um mehr über Event Storming zu lernen: - zentrale Webseite zum Thema: https://www.eventstorming.com/ - Buch von Alberto Brandolini: Introducing EventStorming - An act of Deliberate Collective Learning (leanpub.com/introducing_eventstorming) - Brandolinis Gesetz, auch Bullshit-Asymmetrie-Prinzip - Weitere passende Podcastfolgen Weitere Themen zu bestimmten Podcast-Folgen, auf die Tim im Laufe des Gesprächs hinweist: - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen - Mit Customer Journey Maps arbeiten Jürgen Meurer freut sich über den Kontakt zu euch. Für weitere Fragen rund um das Thema und zu seinen Erfahrungen erreicht ihr ihn am besten auf seinem LinkedIn-Profil (linkedin.com/in/juergen-meurer/). Kanntest du Event Storming bereits vorher? Hast du eventuell selbst schon mal an einer solchen Session teilgenommen? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Have you ever wondered why some teams struggle to adopt Test-Driven Development (TDD) while others excel at it? Join us in this thought-provoking episode as we delve into the challenges of crossing the TDD chasm and explore testing strategies with the insightful Khaled Souf. Are you tired of "freestyling" with no tests? Do you find TDD too hard? We address these questions and more as we discuss the human side of trying to adopt TDD and respond to resistance along the way. Discover the power of supportive guidance and learn how to create an environment where teams can thrive and contribute. But that's not all – we also dive into the world of ensemble programming and the traps that teams often encounter. From the "No Safe Space Trap" to the "Big Steps Trap," we uncover the obstacles that can hinder progress. Find out how to establish lean flow and minimize waste within an ensemble, and explore the balance between strict equality of navigation and minimum viable silence. We also explore the synergy of legacy code and Domain-Driven Design (DDD), showcasing how DDD can be applied while fixing bugs. Don't miss this engaging conversation packed with insights, practical advice, and real-world examples. Subscribe now to our podcast and YouTube channel to be notified when episodes are released. Video and Show Notes: https://youtu.be/XFHzZMlckzU 

Der Produktschnitt im Kontext der agilen Organisationsentwicklung bezieht sich auf die Aufteilung der Teams rund um die Entwicklung eines Produkts oder einer Produktlinie. Es geht darum, die Teams so zu strukturieren, dass sie effektiv und effizient zusammenarbeiten können, um die Produktentwicklung voranzutreiben. Durch eine kluge Aufteilung der Verantwortlichkeiten wird sichergestellt, dass jedes Team über eine klare Aufgabe verfügt und seine Expertise in diesem Bereich entwickeln kann. Der Produktschnitt spielt eine entscheidende Rolle bei der Förderung agiler Prinzipien und der Maximierung des Produkterfolgs. Durch die Aufteilung der Teams nach Produkten, Produktkomponenten oder Kundensegmenten wird eine hohe Spezialisierung ermöglicht. Jedes Team kann sich auf seinen zugewiesenen Bereich konzentrieren und ein tiefes Verständnis entwickeln, was zu schnelleren und effizienteren Ergebnissen führt. Gleichzeitig fördert der Produktschnitt die Zusammenarbeit zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Genauso kann sich dies aber auch gegenteilig auswirken, wenn zu große Abhängigkeiten zwischen den Teams entstehen. **Ansätze für den Produktschnitt** Es gibt verschiedene Ansätze zur Aufteilung der Teams im Produktschnitt, die je nach den Anforderungen und Gegebenheiten der Organisation gewählt werden können. Eine Möglichkeit besteht darin, die Teams nach Produktkomponenten oder den Schritten eines Transaktionsprozesses zu strukturieren. Jedes Team ist dann für einen bestimmten Teil des Produkts verantwortlich und trägt die Verantwortung für dessen Entwicklung und Verbesserung. Eine andere Option besteht darin, die Teams nach Kunden- oder Marktsegmenten oder Regionen zu gliedern, sodass jedes Team auf die Bedürfnisse und Anforderungen einer bestimmten Zielgruppe spezialisiert ist. Eine dritte Möglichkeit ist die Aufteilung nach spezifischen Funktionen, bei der jedes Team bestimmte Aufgaben oder Funktionen übernimmt, unabhängig vom Produkt oder Kundensegment. Die Teamstruktur im Rahmen des Produktschnitts hat viele Vorteile. Einer der wichtigsten Vorteile ist, dass die Teams sich auf spezifische Bereiche fokussieren und ein tiefes Verständnis für diese entwickeln können. Dadurch können sie effektiver arbeiten und spezifischer einen ganz bestimmten Teil des Produkts verbessern, da sie sich auf ihre spezielle Expertise und ein tiefes Nutzerverständnis konzentrieren können. Gleichzeitig erfordert der Produktschnitt die Zusammenarbeit und den Wissensaustausch zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Die Wahl der geeigneten Teamstruktur hängt von verschiedenen Faktoren ab, wie zum Beispiel der Komplexität des Produkts, den Anforderungen der Kunden und den vorhandenen Ressourcen. Es ist wichtig, die Teamstruktur kontinuierlich zu evaluieren und anzupassen, um sicherzustellen, dass die Teams effektiv arbeiten und dass das Produkt schnell und effizient entwickelt wird. Nach unserer Veröffentlichung ist gerade im SoftwareArchitekTOUR-Podcast das fachliche Schneiden mittels Domain Driven Design (DDD) erschienen: "Domain-driven Transformation – Mit DDD Legacy-Systeme transformieren". Findet ihr bei Heise Developer. Welche Erfahrung habt ihr schon mit den verschiedenen Teamstrukturen in der Produktentwicklung gemacht? Waren sie positiv oder gab es Probleme? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/produktschnitt-teamstruktur/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In this episode, Coté is joined by Fouad Hamdi, to discuss a project he worked on to modernize of a 30-year-old mainframe app. Fouad provides a comprehensive breakdown of how he and his team at VMware Tanzu Labs approached this task, migrating a system relied on by over 3 million users from a mainframe infrastructure to a microservices architecture. Read the original blog post they discuss here. Details Fouad and Coté delve into the initial goals for mainframe modernization, the constraints, and past attempts at modernization that shaped the path they took. Fouad shares how they managed to migrate safely and at a rapid pace, all while maintaining the existing system's functionality. Listen as Fouad walks us through how the team  leveraged the power of event storming workshops and Domain Driven Design (DDD) to understand the business domain and identify key areas for modernization. They discuss the challenges of working with older technologies like COBOL, and the strategies they used to bring business knowledge to a new generation of developers. They also explore how the team navigated complex issues such as coexistence between the old and new systems, and how they incrementally built the new system to avoid any disruption of service. Fouad shares invaluable insights into the importance of context in these modernization efforts, and the lessons they learned along the way. Whether you're a software engineer, an architect, or a business leader looking to modernize your own systems, this episode is filled with practical advice and lessons learned from modernizing a mainframe application. Tune in to learn from Fouad's experience and to understand how you can apply these lessons to your own mainframe modernization journey. More Read the original blog post. Fouad's Blog. Fouad in LinkedIn.

In this episode, Coté is joined by Fouad Hamdi, to discuss a project he worked on to modernize of a 30-year-old mainframe app. Fouad provides a comprehensive breakdown of how he and his team at VMware Tanzu Labs approached this task, migrating a system relied on by over 3 million users from a mainframe infrastructure to a microservices architecture. Read the original blog post they discuss here. Details Fouad and Coté delve into the initial goals for mainframe modernization, the constraints, and past attempts at modernization that shaped the path they took. Fouad shares how they managed to migrate safely and at a rapid pace, all while maintaining the existing system's functionality. Listen as Fouad walks us through how the team  leveraged the power of event storming workshops and Domain Driven Design (DDD) to understand the business domain and identify key areas for modernization. They discuss the challenges of working with older technologies like COBOL, and the strategies they used to bring business knowledge to a new generation of developers. They also explore how the team navigated complex issues such as coexistence between the old and new systems, and how they incrementally built the new system to avoid any disruption of service. Fouad shares invaluable insights into the importance of context in these modernization efforts, and the lessons they learned along the way. Whether you're a software engineer, an architect, or a business leader looking to modernize your own systems, this episode is filled with practical advice and lessons learned from modernizing a mainframe application. Tune in to learn from Fouad's experience and to understand how you can apply these lessons to your own mainframe modernization journey. More Read the original blog post. Fouad's Blog. Fouad in LinkedIn.

Neste podcast, vamos juntos explorar com a Kivian Emerim e o Gustavo Mena Barreto os dois padrões de arquitetura de software: o Model-View-Controller (MVC) e o Domain-Driven Design (DDD). Vamos aprofundar os conceitos fundamentais dessas abordagens de desenvolvimento e como podemos usa-las com os recursos RAD do Delphi. Convidados: Kivian Emerim e Gustavo Mena, ambos devs na AquaSoft

Alberto Brandolini joins the podcast as a sparring partner in our exploration of one of the most “burning” issues in our research: the intrinsic links between language, software and organizational design. We explore the role of domain-driven design and, more generally, the role of visualization and context mapping in the process that we call "ontological convergence" i. e. how we agree on standards, converge on using common models and build common tools, protocols and infrastructures.  Alberto, EventStorming creator, Domain-Driven Design (DDD) legend and unconventional entrepreneur, is also famous for the Bullshit Asymmetry Principle aka Brandolini's law. He proudly runs Avanscoperta, a hub for inventing, promoting, and spreading new ideas around software development.  Alberto is also a frequent speaker at conferences and events, and an international trainer with more than ten years of experience. During the chat we explore the ways software drives the adoption of common models and languages, and how the boundaries between technology and business, between one team and another, and even between organizations themselves, are blurring. Alberto observes that, the more you go distributed, the more having clean, well visualized, “bounded contexts” really becomes a key factor in effectiveness and success for organizations. Defining components and modules reduces the need to collectively agree about stuff: an heavily underestimated cost of organizing.  Remember that you can always find transcripts and key highlights of the episode on our website: https://boundaryless.io/podcast/alberto-brandolini    Key highlights 

Über Domain-Driven Design (DDD) sprechen Hans und Vanessa mit dem Gast Florian Benz, VP of Engineering bei Scalable Capital. Florian beleuchtet dabei vor Allem dir Umsetzung samt Stolpersteinen in der…

Dragan Stepanović is a Senior Principal Engineer at Talabat. Dragan has experience working at different sizes of companies, from small to large corporates. He became interested in Extreme Programming (XP) early on in his career. Then, he started diving into architecture, Domain Driven Design (DDD) and LEAN as tools to enable engineers to maximise their throughput for their stakeholders.Renato Rodrigues de Araujo is a Senior Software Engineer at Form3. Renato is part of the Tooling Team, which is responsible for making the lives of engineers easier by maintaining internal tools.Our  .tech series invites guests inside and outside of Form3, discussing current trends in the engineering world alongside shedding light into some of the engineering practices here at Form3. Get in touch with us via this short form if you'd like to be  a podcast guest. 

Afinal, qual a relevância do DDD para CTO's e líderes técnicos? Neste episódio conversamos com o Eduardo e o Gilmar sobre os seus pontos de vista sobre Domain Driven Design (DDD)! Um pequeno time ou uma pessoa desenvolvedora sozinha consegue implementar o DDD? Por que é interessante o DDD na perspectiva de líderes como CTO's? O que DDD e Flight Levels tem a ver? Como o negócio pode se beneficiar? Essas são algumas das perguntas que são respondidas neste episódio do TallerCast! Bom episódio!

Brent, Dennis, and Philipp have a conversation about Domain Driven Design (DDD). As part of the discussion, they also cover the relationships with microservices, design thinking, the various classifications in DDD and the Business Model Canvas.

We had a conversation with Kenny Baas-Schwegler (from Xebia), who is a strategic software delivery consultant and software architect with a focus on socio-technical systems. With his guidance, we deep-dived into Domain-Driven Design (DDD) and Deep Democracy. How can fluidity and upfront communication help to create a shared language and understand the other's needs? How does this help an organization to move forward with its strategy? With collaborative modelling (like eventstorming) teams can experience the complexity within their organization. From there, it is possible to create a structure, but keep in mind that the structures are continuously evolving, they are not static. Hosts are Kristof Van Tomme (CEO & Co-founder, Pronovix), and Marc Burgauer (Principal Consultant and Co-founder at Contextualise).

https://www.patreon.com/datameshradio (Data Mesh Radio Patreon) - get access to interviews well before they are released Episode list and link to all available episode transcripts (most interviews from #32 on) https://docs.google.com/spreadsheets/d/1ZmCIinVgIm0xjIVFpL9jMtCiOlBQ7LbvLmtmb0FKcQc/edit?usp=sharing (here) Provided as a free resource by DataStax https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB) Ole's Book (O'Reilly Early Release): https://www.oreilly.com/library/view/the-enterprise-data/9781492098706/ (https://www.oreilly.com/library/view/the-enterprise-data/9781492098706/) Transcript for this episode (https://docs.google.com/document/d/1wWCM6AQJ0GtGmYJ7XFR-kSUfWv2jzxVp4jUApNDSyMk/edit?usp=sharing (link)) provided by Starburst. See their Data Mesh Summit recordings https://www.starburst.io/learn/events-webinars/datanova-on-demand/?datameshradio (here) and their great data mesh resource center https://www.starburst.io/info/distributed-data-mesh-resource-center/?datameshradio (here) In this episode, Scott interviewed Ole Olesen-Bagneux, an Enterprise Architect who focuses on data at GN and the author of an upcoming book on data catalogs with O'Reilly. To be clear, Ole was only representing himself and not GN. The two main topics, which are somewhat intertwined, were: 1) how can we better understand and handle the concept of a domain when discussing data; and 2) how can we build systems that better enable us to search "for" data, not just search "in" data that we know exists? Some practical advice and general conclusions from Ole: Leverage what the Library and Information Sciences discipline - which is centuries (millennia?) old - has formed around the domain concept. It will help you better dig into the actual business dealings of the domain first before trying to focus too much on the technical/software aspects. The software aspects hinder your initial domain mapping - especially in depth - and business context understanding when you start from a DDD perspective in data. Spend a lot more time on enabling people to understand what data is available. We focus a lot on optimizing for searching "in" data, but we don't spend near enough time setting up our systems to allow people to search "for" data. To do that, work seriously on your metadata tools system and look for ways to harmonize data across those tools. Ole started the conversation sharing his view that Domain Driven Design (DDD) has some shortcomings when used especially for data domain mapping and in general in data. In his view, DDD is overly tied to software engineering so there is too much of a technical bent to understanding and even mapping out domains. He recommends taking domain analysis and domain theory learnings from the Library and Information Sciences discipline and using that to start your domain mapping and then look to bring in DDD after you get a good initial understanding of your domains. DDD and domain analysis can work together harmoniously, they don't really contradict, but domain analysis focuses on the knowledge first instead of the technical first. While Ole was inspired by Zhamak's book as well as the book by Piethein Strengholt, his believes domain analysis lowers the significant friction and often frustration organizations feel when trying to start doing DDD for data. Domain analysis digs much more into what the domain does and why instead of how the domain communicates via software. He believes that data mesh should focus more on the information sharing and less on the software and that DDD will overcomplicate your domain mapping. For Ole, DDD is overly concerned with modeling domains into software but you need to get to a deeper understanding of your domains and organization first before focusing in on your model. It may be that you truly can't fully communicate your domain's context in a data model either and it's good to know that upfront and take steps to communicate in other...

“It is good to improve your processes to make them faster and more efficient. But sometimes what's even more important is doing the right thing in the first place." Scott Wlaschin is the author of “Domain Modeling Made Functional” and the popular F# site fsharpforfunandprofit.com. In this episode, Scott began by sharing his view of the need for developers today to become more polyglot developers and learn multiple programming languages. Scott then shared about functional programming (FP) fundamentals and how FP differs with object-oriented programming, as well as cases when one is better suited than the other. Scott then explained how we can use FP when implementing Domain-Driven Design (DDD), including how to model some of the DDD tactical designs and transaction boundary. He also shared why F# is his favorite and go-to programming language. Towards the end, Scott touched on important advice about effectiveness vs efficiency, and what leaders need to be aware of regarding doing the right thing. Listen out for: Career Journey - [00:06:16] Polyglot Developer - [00:11:01] Functional Programming - [00:14:59] Case for OOP - [00:19:56] DDD and FP - [00:21:02] Modeling Tactical Design in FP - [00:24:10] Modeling Transaction - [00:28:49] F# - [00:32:22] Effective Instead of Efficient - [00:34:43] Advice on Valuing Effectiveness - [00:38:31] 3 Tech Lead Wisdom - [00:40:30] _____ Scott Wlaschin's Bio Scott Wlaschin is a developer, architect and author. He is the writer behind the popular F# site fsharpforfunandprofit.com, and the book ‘Domain Modeling Made Functional' published by Pragmatic Bookshelf. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world. Follow Scott: Twitter – @ScottWlaschin LinkedIn – https://www.linkedin.com/in/scottwlaschin F# for Fun and Profit – https://fsharpforfunandprofit.com/ Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/79.

Provided as a free resource by DataStax https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB) In this episode, Scott interviews two Domain Driven Design (DDD) experts from Thoughtworks - Danilo Sato Director and the Head of Data & AI (part of Office of the CTO) and Andrew Harmel-Law, Technical Principal. This was a further delve into Domain Driven Design for Data after the conversations with Paolo Platter and Piethein Strengholt. Danilo and Andrew gave a lot of great information about Event Storming, domain definitions and boundaries, ubiquitous language, and so much more but the main theme was "just get people to talk to each other". DDD is about bridging the gap between how the tech people talk and how the business/business people talk; if you are doing it right, both sides can understand each other and then the engineers can implement those business process learnings as part of the code. For an initial PoC, Danilo recommends starting with 2-3 data products. It is better if you can do the PoC across multiple domains but it isn't necessary. Validate value and do it quickly. As Andrew mentions, the earlier you can show value, the less pressure there is overall. Look for the initial quick wins while also building for the long-term. One key thing to remember, per Danilo, when doing DDD for data and data mesh in general: it is always an iterative process. Andrew briefly discussed a way to do DDD in more of a guerilla style than the blue/red books (well known DDD guides). Don't get ahead of yourself as Max Schultze mentioned in his episode. Do not let the size of the eventual task throw you into analysis paralysis. Andrew talked a lot about how normalization and strong abstractions on the application side make it very difficult to re-add the context lost when you normalize. Both Andrew and Danilo talked about the need to embrace complexity. If you want context, you have to accept there will be complexity. In the pursuit of simplification, you lose the richness, and that is VERY hard to reconstruct afterwards. Some practical advice for boundary definition is that the boundaries need to be very clear but malleable. Build everything with an eye that it will evolve. Before you start splitting into many 2 pizza teams, look at the big picture and select some coarse-grained boundaries. It is MUCH easier to split later than it is to glue things back together. Danilo's Webinar with Zhamak called "Data mesh and domain ownership": https://www.thoughtworks.com/en-us/about-us/events/webinars/core-principles-of-data-mesh/data-mesh-and-domain-ownership (https://www.thoughtworks.com/en-us/about-us/events/webinars/core-principles-of-data-mesh/data-mesh-and-domain-ownership) Vladik Khononov, 7 Years of DDD: https://www.youtube.com/watch?v=h_HjtYAH0AI (https://www.youtube.com/watch?v=h_HjtYAH0AI) Danilo LinkedIn: https://www.linkedin.com/in/danilosato/ (https://www.linkedin.com/in/danilosato/) Danilo Twitter: @dtsato / https://twitter.com/dtsato (https://twitter.com/dtsato) Andrew LinkedIn: https://www.linkedin.com/in/andrewharmellaw/ (https://www.linkedin.com/in/andrewharmellaw/) Andrew Twitter: @al94781 / https://twitter.com/al94781 (https://twitter.com/al94781) Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him at community at datameshlearning.com or on LinkedIn: https://www.linkedin.com/in/scotthirleman/ (https://www.linkedin.com/in/scotthirleman/) If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/ (https://datameshlearning.com/community/) If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see https://docs.google.com/document/d/1WkXLhSH7mnbjfTChD0uuYeIF5Tj0UBLUP4Jvl20Ym10/edit?usp=sharing (here) All music used this episode created by Lesfm (intro includes slight edits by Scott Hirleman): https://pixabay.com/users/lesfm-22579021/...

“Interactions with domain experts play a key role in implementing software. You have to make sure that you understand the problem you're solving. You cannot provide a software solution without understanding the problem first." Vladik Khononov is the author of “Learning Domain-Driven Design”. In this episode, we discussed in-depth about Domain-Driven Design (DDD) and Vlad started by sharing why understanding business domain is crucial in software engineering and how DDD can help build the shared understanding between domain experts and software engineers. Vlad then explained the two important designs in DDD, i.e. the strategic and tactical designs, and how they relate to each other. For each design, Vlad touched on some important patterns, such as bounded context, context map, subdomain, aggregate, entity, and value object. Towards the end, Vlad gave great tips on applying DDD to brownfield projects and how those projects can benefit the most from some of the DDD practices. Listen out for: Career Journey - [00:06:05] Importance of Understanding Business Domain - [00:10:42] How Domain-Driven Design Helps - [00:16:12] DDD Strategic Design - [00:20:21] Subdomain - [00:26:51] DDD Tactical Design - [00:32:44] Aggregate Pattern - [00:34:36] Entity Pattern - [00:40:43] Implementing DDD for Legacy System - [00:43:24] 3 Tech Lead Wisdom - [00:46:52] _____ Vladik Khononov's Bio Vlad (Vladik) Khononov is a software engineer with over 20 years of industry experience, during which he has worked for companies large and small in roles ranging from webmaster to chief architect. Vlad maintains an active media career as an author, public speaker, and blogger. He travels the world consulting and talking about domain-driven design, microservices, and software architecture in general. Vladik lives in Northern Israel with his wife and an almost-reasonable number of cats. Follow Vladik: Twitter – @vladikk LinkedIn – https://www.linkedin.com/in/vladikkhononov/ Website – https://vladikk.com/ Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/76.

Provided as a free resource by DataStax https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB) Scott interviews Piethein Strengholt, Senior Cloud Solution Architect at Microsoft and author of the O'Reilly book Data Management at Scale. Piethein shares his tips and tricks for how to approach Domain Driven Design (DDD) for data. There are puts and takes to each approach so unfortunately for those looking for an easy button, there is a lot to consider. When starting, Piethein recommends looking at your applications and deciding if there is a logical mapping to a single domain or if the application is shared across domains. As you learn more about DDD you can start to approach your domains from multiple other angles to find the best solution for your org. There is a ton of really great advice, too much to sum up well here. Scott highly recommends reading https://towardsdatascience.com/data-domains-where-do-i-start-a6d52fef95d1 (this article) on data domains by Piethein before jumping in to the podcast episode. Mentioned articles and books: Data Management at Scale book: https://www.oreilly.com/library/view/data-management-at/9781492054771/ (https://www.oreilly.com/library/view/data-management-at/9781492054771/) Data Domains — Where do I start? https://towardsdatascience.com/data-domains-where-do-i-start-a6d52fef95d1 (https://towardsdatascience.com/data-domains-where-do-i-start-a6d52fef95d1) Implementing Data Mesh on Azure: https://towardsdatascience.com/implementing-data-mesh-on-azure-c01ee94306cd (https://towardsdatascience.com/implementing-data-mesh-on-azure-c01ee94306cd) Data Domains and Data Products: https://towardsdatascience.com/data-domains-and-data-products-64cc9d28283e (https://towardsdatascience.com/data-domains-and-data-products-64cc9d28283e) "The Blue Book" AKA Domain-Driven Design: Tackling Complexity in the Heart of Software: https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/ (https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/) Find Piethein online: LinkedIn: https://www.linkedin.com/in/pietheinstrengholt/ (https://www.linkedin.com/in/pietheinstrengholt/) Twitter: @phstrengholt / https://twitter.com/phstrengholt (https://twitter.com/phstrengholt) Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him at community at datameshlearning.com or on LinkedIn: https://www.linkedin.com/in/scotthirleman/ (https://www.linkedin.com/in/scotthirleman/) If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/ (https://datameshlearning.com/community/) If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see https://docs.google.com/document/d/1WkXLhSH7mnbjfTChD0uuYeIF5Tj0UBLUP4Jvl20Ym10/edit?usp=sharing (here) All music used this episode created by Lesfm (intro includes slight edits by Scott Hirleman): https://pixabay.com/users/lesfm-22579021/ (https://pixabay.com/users/lesfm-22579021/) Data Mesh Radio is brought to you as a community resource by DataStax. Check out their high-scale, multi-region database offering (w/ lots of great APIs) and use code DAAP500 for a free $500 credit (apply under "add payment"): https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB)

“Strategy is what earns. Use the strategic and innovative drivers to help us determine what our architecture needs to be. Architecture has to have a purpose." Vaughn Vernon is a leading expert in Domain-Driven Design (DDD) and he recently co-authored his new book “Strategic Monoliths and Microservices”. In this episode, Vaughn shared his story and rationale for writing his new book and why he thinks it is important to include the executives as the readers of the book. He emphasized the importance of focusing on strategic innovative aspects of software development and for driving those innovations using purposeful architectures. Vaughn then shared his insightful perspective on Conway's Law and why he compares it with the law of gravity. We then discussed two important architectural aspects covered in the book, which are events first architecture and embracing latency, and why they are actually natural to how people communicate and get things done in real life. Towards the end, Vaughn summed up his book and left an important piece of advice that he wanted to convey regarding monoliths vs microservices and why software should require more balance and demand a better strategy. Listen out for: “Strategic Monoliths and Microservices” Book - [00:06:32] Who Should Read the Book - [00:12:31] Strategic Learning and Experimentation - [00:16:48] Purposeful Architecture - [00:22:04] Conway's Law - [00:27:24] Events First Architecture - [00:33:48] Embrace Latency - [00:38:54] Monoliths vs Microservices - [00:47:30] 3 Tech Lead Wisdom - [00:52:16] _____ Vaughn Vernon's Bio Vaughn Vernon is an entrepreneur, software developer, and architect with more than 35 years of experience in a broad range of business domains. Vaughn is a leading expert in Domain-Driven Design and reactive software development, and a champion of simplicity. Vaughn is the founder and chief architect of the VLINGO/PLATFORM, and he consults and trains around Domain-Driven Design, reactive software development, as well as EventStorming and Event-Driven Architecture, helping teams and organizations realize the potential of business-driven and reactive systems as they transform their businesses from technology-driven legacy web implementation approaches. Vaughn is the author of four best-selling books, as well as the curator and editor of his own Vaughn Vernon Signature Series, all published by Addison-Wesley. Follow Vaughn: LinkedIn – https://www.linkedin.com/in/vaughnvernon/ Twitter – @VaughnVernon Website – https://vaughnvernon.com/ Github – https://github.com/VaughnVernon VLINGO – https://vlingo.io DomoRoboto – https://domorobo.to/ Our Sponsor Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags by visiting https://techleadjournal.dev/shop. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/71.

“Time is important for business. We have to model it explicitly. Temporal modeling means that we use time-based artifacts as first modeling citizens." Tomasz Jaskula is the CTO and co-founder of Luteceo and an experienced software developer and architect. In this episode, we started off discussing how Domain-Driven Design (DDD) influenced Tomasz's view on software development approach and its relation with functional programming. Tomasz then explained in depth about the time concept in business applications and temporal modeling, in particular, bi-temporal modeling. He mentioned the different concepts of time in temporal modeling, explaining them using an example for easier illustration. We then extended our discussion further to Event Sourcing, understanding the key concept, its relation to temporal modeling, when we should decide to use Event Sourcing in our application, and some available tools that can help us implement Event Sourcing. Listen out for: Career Journey - [00:04:58] DDD and Bounded Context - [00:08:56] DDD and Functional Programming - [00:13:24] Temporal Modeling - [00:14:47] 3 Different Types of Time - [00:21:13] Event Sourcing - [00:25:42] When to Use Event Sourcing - [00:28:13] Event Sourcing Tools - [00:34:02] 3 Tech Lead Wisdom - [00:36:10] _____ Tomasz's Bio Tomasz Jaskuła is CTO and co-founder of Luteceo, a software consulting company in Paris. Tomasz has more than 20 years of professional experience as a developer and software architect, and worked for many companies in the e-commerce, industry, insurance, and financial fields. He has mainly focused on creating software that delivers true business value, aligns with strategic business initiatives, and provides solutions with clearly identifiable competitive advantages. Tomasz is also a main contributor to the OSS project XOOM for the .NET platform. In his free time, Tomasz perfects his guitar playing and spends time with his family. He recently wrote a book with Vaughn Vernon titled “Strategic Monoliths and Microservices” published by Addison-Wesley. Follow Tomasz: LinkedIn – https://www.linkedin.com/in/tomasz-jaskula-16b2823/ Twitter – @tjaskula Luteceo – http://luteceo.com Our Sponsor Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags by visiting https://techleadjournal.dev/shop. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/66.

Im heutigen Interview spreche ich mit Sebastian Henneberg, Head of Software Engineering bei FuPa.net, der Community-Plattform für den Amateurfußball, über Domain-Driven Design (DDD), die Integration von Microservices mit Amazon EventBridge und Single-Table-Design. Links zur Sendung: FuPa - Aus Liebe zum Fußball (https://www.fupa.net) What is an Event-Driven Architecture? (https://aws.amazon.com/event-driven-architecture) The What, Why, and When of Single-Table Design with DynamoDB (https://www.alexdebrie.com/posts/dynamodb-single-table) Sebastian bei LinkedIn (https://www.linkedin.com/in/sebastianhenneberg) Sebastians Vortrag bei der AWS Usergroup Niederbayern am 27.10.2021 (https://www.meetup.com/de-DE/niederbayern-aws-user-group/events/280936918) Der offizielle deutschsprachige Podcast rund um Amazon Web Services (AWS), für Neugierige, Cloud-Einsteiger und AWS-Experten, produziert von Dennis Traub, Developer Advocate bei AWS. Bei Fragen, Anregungen und Feedback wendet euch gerne direkt an Dennis auf Twitter (@dtraub) oder per Mail an traubd@amazon.com. Für mehr Infos, Tipps und Tricks rund um AWS und die Cloud folgt Dennis auf: Twitter - https://twitter.com/dtraub LinkedIn - https://www.linkedin.com/in/dennis-traub YouTube - https://www.youtube.com/dennistraub

“Programmers have to come out of their cubicles. Innovative software development doesn’t happen with one person in a cubicle with great ideas. Because it’s not just even about code. Anybody can write code. It’s about what does the code accomplish. And if the code accomplishes something innovative, great!" Vaughn Vernon is a leading expert in Domain-Driven Design (DDD) and reactive software development. He is well-known for his best-selling DDD books and IDDD workshops. In this episode, we discussed many things about Domain-Driven Design and Event-Driven Architecture (EDA). Apart from the fundamentals, Vaughn shared many of his insights around the two, such as why developers should learn more about DDD, the most important aspect of DDD, the benefits of EDA, eventual consistency, event storming, and event sourcing. Towards the end, Vaughn also gave a sneak peek about his new book “Strategic Monoliths and Microservices” and why he wrote it. Listen out for: Vaughn’s career journey - [00:06:44] Domain-Driven Design - [00:16:47] Why DDD can be expensive - [00:21:43] Why developers need to know DDD - [00:23:59] DDD most important thing - [00:27:15] How to start with DDD - [00:30:05] Event-Driven Architecture - [00:32:28] Benefits of EDA - [00:36:00] Eventual consistency - [00:40:13] Event storming - [00:45:22] Event sourcing - [00:49:13] Vaughn’s new book - [00:53:09] Vaughn’s 3 Tech Lead Wisdom - [01:00:26] _____ Vaughn Vernon’s Bio Vaughn Vernon is an entrepreneur, software developer, and architect with more than 35 years of experience in a broad range of business domains. Vaughn is a leading expert in Domain-Driven Design and reactive software development, a champion of simplicity, and he is the founder and chief architect of the VLINGO/PLATFORM. Along with his three best-selling books, Vaughn was recently commissioned by Pearson/Addison-Wesley as curator and editor of his own Vaughn Vernon Signature Series. Follow Vaughn: Website - https://vaughnvernon.com/ Twitter - https://twitter.com/VaughnVernon LinkedIn - https://www.linkedin.com/in/vaughnvernon/ Our Sponsor Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags by visiting https://techleadjournal.dev/shop. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/21.

Рад представить вам 126-й выпуск подкаста, в котором мы говорим про Domain Driven Design (DDD) и unit-тестирование. У меня в гостях Владимир Хориков, автор книги про Unit-тестирование и блога Enterprise Craftmanship. Володя рассказал про своё знакомство с DDD, первые опыты внедрения, насколько не просто было внедрить идею DDD будучи не тимлидом, а просто программистом. Так же Володя рассказал как сейчас обычно происходит внедрение DDD, с чего начинается обучение команды. Мы обсудили как DDD подход ложится в ООП парадигму разработки, разобрали применение DDD в MVC/MVVM подходах к построению UI. Подискутировали о применении DDD в купе с CQRS и Event Sourcing. Второй большой темой обсуждения стало тестирование. Володя рассказал про unit и интеграционные тесты. Мы обсудили их место в пирамиде тестирования, соотношение количества тестов разных видов. Володя поделился своим мнением о том, что должны тестировать unit-тесты, как тестировать и какие у тестов есть метрики качества. Помимо этого Володя рассказал про написание книги: зачем он решил написать, сколько сил и времени у него на это ушло и какой получился результат. Ссылки на ресурсы по темам выпуска: * Статья в блоге «Types of CQRS» (https://enterprisecraftsmanship.com/posts/types-of-cqrs/) * Статья в блоге «Entity vs Value Object: the ultimate list of differences» (https://enterprisecraftsmanship.com/posts/entity-vs-value-object-the-ultimate-list-of-differences/) * Статья в блоге про закон Деметры и неизменяемость «Law of Demeter and immutability» (https://enterprisecraftsmanship.com/posts/law-of-demeter-and-immutability/) * Книга Володи: * На английском «Unit Testing Principles, Practices, and Patterns: Effective testing styles, patterns, and reliable automation for unit testing, mocking, and integration testing with examples in C#» (https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns/dp/1617296279) * На русском «Принципы юнит-тестирования» (https://www.piter.com/product/printsipy-yunit-testirovaniya) Понравился выпуск? — Поддержи подкаст на patreon.com/KSDaemon (https://www.patreon.com/KSDaemon), звёздочками в iTunes (https://podcasts.apple.com/ru/podcast/software-development-podcast/id890468606?l=en), а так же ретвитом или постом! Заходи в телеграм-чат SDCast (https://t.me/SDCast), где можно обсудить выпуски, предложить гостей и высказать свои замечания и пожелания!

David Felkel, who joins to talk about Domain-Driven Design, is a Munich based Salesforce developer, software engineer, scrum master. He is also on his freelancer journey. Main points What is Domain-Driven Design (DDD)? Ubiqitous language and its natural synergy with Salesforce Technical DDD in Salesforce – how is it limited? DDD and Apex – what can be used in Salesforce? How to learn DDD Links David’s LinkedIn Video Teaser The YouTube Video URL The post 83. Domain-Driven Design | David Felkel appeared first on SalesforceWay.

Domain-driven design and extreme programming can help bridge the gap between development and business, and today we invite Mark Windholtz from Agile DNA to talk about how! Mark starts out by telling us about his early work in extreme programming before agile was a term and how he switched from Rails to Elixir after realizing its power for implementing domain-driven design. We take a deep dive with him into what these concepts mean, hearing him weigh in on how DDD can help architecture accommodate both development and business oriented complexities. For Mark, development and business teams must get a better understanding of each other’s jargon, and DDD is a way to accomplish this. The goal is to find a way of building a solid software core and to move away from features to systems thinking, whereby flexible software can make it more possible to do agile on the business side. We chat about some of the practices and principles that come into play when implementing DDD for Mark, and he details concepts like ubiquitous language, bounded contexts, and how to focus on the core domain by exploring models using tactical and strategic patterns. Along with this, Mark discusses users not being a domain concept, the challenges of getting new terms to stick in teams’ minds, and the task of refactoring code to reflect updated glossaries. Near the end of our conversation, Mark drills down on how DDD can optimize team efficiency. In closing, we get to know Chris Bell from ElixirTalk a little better in this week’s edition of Pattern Matching with Todd! Key Points From This Episode: Thoughts on SpaceEx and their approach to engineering: system versus feature optimization. Mark’s background in extreme programming, how he got started with AgileDNA, and the work they do there. A definition of extreme programming that adds engineering practices to Scrum. Elixir’s superior ability to do DDD compared to Rails and how Mark got started using it. A brief introduction to domain-driven design, an approach to simplifying complex software. How architecture needs to accommodate essential as well as accidental complexity. Elixir’s ability to accommodate the building of domain models with well-separated code chunks. Principles of ubiquitous language and bounded contexts that make up DDD for Mark. Ubiquitous language helps devs and businesspeople understand each other. Bounded contexts: ‘Within this space, this world means this thing.’ Shifting focus from trying to make not all software, but core software, good. What patterns are applied to use principles of ubiquitous language and bounded contexts. Finding and focusing on the core domain by exploring models and how to do this using tactical and strategic patterns. The consequences of users not being a domain concept which demands having a clearer language. Challenges of getting language and concepts to stick in business people’s minds. Refactoring code to reflect updated glossaries: Technical challenges teams doing DDD face. Switching paradigms from feature-based optimizations to building an amazing code core. Approaches to modeling: the value of exploring multiple models. How teams can become more efficient using DDD and extreme programming. Final plugs from Mark and how Agile DNA can help use Elixir to implement DDD. Pattern matching: Todd gets to know more about Chris Bell from ElixirTalk. How Chris got into programming, what he’d do if not be a programmer, and more! Why Chris loves history, dream pop, and what movie he’ll watch over and over. What project Chris is most excited about next: Building Settlers of Catan using LiveView. Links Mentioned in Today’s Episode: Elixir Wizards Listener Survey — https://smr.tl/podcastsurvey SmartLogic — https://smartlogic.io/ Mark Windholtz on LinkedIn — https://www.linkedin.com/in/mwindholtz/ Mark Windholtz on Twitter — https://twitter.com/windholtz Agile DNA — http://www.agiledna.com Chris Bell on Twitter — https://twitter.com/cjbell?lang=en ElixirTalk — http://elixirtalk.com/ Chris Keathley — https://keathley.io/ Elon Musk — https://www.forbes.com/profile/elon-musk/#5bbe73cc7999 The Everyday Astronaut — https://www.youtube.com/channel/UC6uKrUWqJ1R2HMTY3LIx5Q Rob Martin — https://www.linkedin.com/in/version2beta/ Perhap — https://github.com/Perhap/perhap Andrew Hao — https://github.com/andrewhao Fred Brooks — http://www.cs.unc.edu/~brooks/ The Mythical Man-Month — https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959 Zach Thomas — https://github.com/zdcthomas?language=elixir&tab=stars 1917 — https://www.imdb.com/title/tt8579674/ Real Estate — https://www.realestatetheband.com/ Galaxie 500 — https://pitchfork.com/artists/1673-galaxie-500/ Star Trek: First Contact — https://www.imdb.com/title/tt0117731/ Star Trek: The Wrath of Khan — https://www.imdb.com/title/tt0084726/ LiveView — https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html Lonestar Elixir — https://lonestarelixir.com/ Special Guest: Mark Windholtz.

Chris and Austin have an engaging discussion on all things Domain Driven Design (DDD) and Mob Programming with Pluralsight author Julie Lerman (https://twitter.com/julielerman). Topics include mob programming DDD, DDD collaboration, and mob programming legacy code. Video and show notes: https://youtu.be/k59-OS5OqHg 

Domain-Driven Design (DDD) provides much of the strategic design guidance that we can use to determine the boundaries around and interactions between Microservices in our solutions. DDD also follows up with tactical design patterns for your business logic. In this session we'll take a look at some of these patterns and how EF Core naturally, or with some additional configuration, persists the data that your microservices depend on.

When designing organizations for fast flow of change, we need to find effective boundaries between different streams of change. Techniques like Domain-Driven Design (DDD) are very powerful for this but can be quite involved and difficult to learn. A lightweight intermediate approach is to ask "could this thing be run as a cloud-hosted (SaaS) service or product?". This session explores the Independent Service Heuristics, a kind of “DDD-Lite” approach based on some ideas in the book Team Topologies by Matthew Skelton and Manuel Pais. The Independent Service Heuristics help teams to find candidate services and domains for running as a separate value stream or separate service. The Independent Service Heuristics have proven useful for various organizations improving flow. In this session, we would really welcome feedback and critique of the approach. Where might the approach not work? What pitfalls might there be? Are there questions or material missing? See the Independent Service Heuristics on GitHub at https://github.com/TeamTopologies/Independent-Service-Heuristics - send a Pull Request! The material is Creative Commons CC BY-SA.

 A adoção do padrão arquitetural Domain Driven Design (DDD) ou em Modelagem Orientada ao Domínio ainda é um desafio. Neste episódio eu Douglas Ramalho como hoster e o Adriano Ribeiro vamos conversar sobre o que é DDD afinal? Falaremos de alguns dos padrões que são centro da arquitetura como: Repository, Factory, Aggregation, Entity e Value Object; desafios, problemas da adoção parcial, possibilidades com a adoção e referências como os livros dos mestres: Eric Evans, Vaughn Vernon, Greg Young e Chris Richardson.  Tópicos: Nasce o Road Dev Podcast Introdução do episódio Contextualização sobre DDD Complexidades do DDD Principais elementos Falando de Agregações Erros e acertos que cometemos ao aplicar DDD Ferramentas que potencializam a modelagem de domínio Referências Encerramento Arte do episódio por Pixabay do Pexels música The J por texasradiofish (c) copyright 2020 Licensed under a Creative Commons Attribution Noncommercial  (3.0) license. http://dig.ccmixter.org/files/texasradiofish/61420 Ft: ElRon XChile, Admiral Bob --- Send in a voice message: https://anchor.fm/roadtoagility/message

Taktisches Design ist ein wichtiges Werkzeug von DDD, das nun das zentrale Thema einer weiteren Episode des SoftwareArchitekTOUR-Podcast einnimmt.

In der dritten Episode zum Domain-Driven Design geht es um die Themen Event Storming und Domain Story Telling.

Gernot Starke, Carola Lilienthal und Eberhard Wolff beschäftigen sich erneut mit Domain-Driven Design (DDD) – dieses Mal mit dem Schwerpunkt auf Strategic Design.

Gernot Starke, Carola Lilienthal und Eberhard Wolff beschäftigen sich in dieser Episode des SoftwareArchitekTOUR-Podcast mit Domain-driven Design (DDD).

Vaughn Vernon is thought-leader in the space of reactive software and Domain Driven Design (DDD). Vaughn has recently released a new open source project called vlingo. The platform is designed to support DDD at the framework and toolkit level. On today’s podcast, Vaughn discusses what the framework is all about, why he felt it was needed, and some of the design decisions made in developing the platform, including things like the architecture, actor model decisions, clustering algorithm, and how DDD is realized with the framework. Why listen to this podcast: - Vlingo is an open source system for building distributed, concurrent, event-driven, reactive microservices that supports (at the framework level) Domain Driven Design. - The platform is in the early stages. It runs on the JVM. There is a port to C#. All code is pushed up stream. - The platform uses the actor model and all messages are sent in a type-safe way. - Vlingo supports clustering and uses a bully algorithm to achieve consensus. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2MwEWxb You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2MwEWxb

Wes Reisz sits down and chats with Uncle Bob about The Clean Architecture, the origins of the Software Craftsperson Movement, Livable Code, and even ethics in software. Uncle Bob discusses his thoughts on how The Clean Architecture is affected by things like functional programming, services meshes, and microservices. Why listen to this podcast: * Michael Feathers wrote to Bob and said if you rearrange the order of the design principles, it spells SOLID. * Software Craftsperson should be used when you talking about software craftsmanship in a gender-neutral way to steer clear of anything exclusionary. * Clean Architecture is a way to develop software with low coupling and is independent of implementation details. * Clean Architecture and Domain Driven Design (DDD) are compatible terms. You would find the ubiquitous language and bounded context of DDD at the innermost circles of a clean architecture. * Services do not form an architecture. They form a deployment pattern that is a way of decoupling and therefore has no impact on the idea of clean architecture. * There is room for “creature comforts” in a code base that makes for more livable, convenient code. * “We have no ethics that are defined [in software].” If we don’t find a way to police it ourselves, governments will. We have to come up with a code of ethics. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Nebspj You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Nebspj

Domain-Driven Design (DDD) é uma forma de desenvolver software que foca em implementar o melhor design de software baseado em modelos que refletem explicitamente as competências da organização. Os apresentadores conversam sobre a relação do DDD com o DevOps. Referências e mais detalhes em: https://www.10deploys.com/episodios/001-domain-driven-design

This month on the Cucumber podcast, Aslak Hellesøy and Steve Tooke speak to Kenny Baas and Bruno Boucard about the relationship between Domain-Driven Design (DDD) and Behaviour-Driven Development (BDD). While both share many similarities, there isn't a great deal of crossover between the two communities. Our two guests want to change that by demonstrating that both practices and communities have more in common than they may think. ### Show notes [Kenny's article about DDDBDD](http://blog.xebia.com/combining-domain-driven-design-and-behaviour-driven-development/) [Bruno on Twitter](https://twitter.com/brunoboucard)/ [Kenny on Twitter](https://twitter.com/kenny_baas) [DDD conference in Denver, Sept 2018](http://exploreddd.com/) [Event Storming introduction](http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html) [Example Mapping introduction](https://cucumber.io/blog/2015/12/08/example-mapping-introduction) [Kanddinsky Conference, Berlin, October 2018](https://kandddinsky.de/) [Cucumber on Twitter](https://twitter.com/cucumberbdd)

In this episode, we discuss buying a new Apple iPhone and changes to Siri search, Marc Benioff's birthday and being awarded by Variety, Equifax CEO resigning, ProsperWorks raising $53 million to compete with Salesforce.com, and answer questions from the Good Day, Sir! Slack Community. Apple Drops Bing Search Engine Results for Siri and Spotlight in Favor of Google Priyanka Chopra, Octavia Spencer, Michelle Pfeiffer, Patty Jenkins, Kelly Clarkson to Be Honored at Variety’s Power of Women A CEO's Demise: Lessons From Equifax ProsperWorks raises $53 million to take on Salesforce’s CRM Waze App Uber Eats Domain Driven Design (DDD)

In this episode, we discuss the snowball affect of subscription services, Thoughtworks Technology Radar, Skuid's Brooklyn Release, and Domain-Driven Design (DDD). Salesforce Einstein: How A Machine Brain Learns Technology Radar Nov '16 Aquafold DBeaver Skuid Platform—A new era of cloud apps and great UX Domain-driven design Domain-Driven Design: Tackling Complexity in the Heart of Software 1st Edition Patterns of Enterprise Application Architecture 1st Edition

Neste episódio do podcast o Abner das Dores, Giovanni Bassi, Heber Pereira, Thiago Holder e o host, Vinicius Quaiato, conversam sobre DDD (Domain Driven Design), o que não é DDD, porque existe referências que focam em Repositórios, o que é Domain Drive Design, a importância da Ubiquitous Language (Linguagem Onipresente), bounded context e dicas de estudos para entender o DDD. Um bate-papo interessante para quem quer saber mais sobre esse conceito que vem ganhando mais espaço e boas discussões. Se você quer saber mais sobre o assunto tem que ouvir! Comente sobre o episódio aqui no blog da Lambda3 ou nas nossas redes sociais. E se você gostou divulgue-nos, os links estão abaixo. Se você não gostou, mande a sua crítica, vamos analisá-la e pensar o que podemos fazer, para você ter um podcast cada vez melhor! Feed do podcast: blog.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos:blog.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos:blog.lambda3.com.br/feed/podcast-nao-tecnico Pauta: O que não é DDD? O que é Domain Driven Design? DDD é uma arquitetura? Porque o DDD se tornou um modelo para o desenvolvimento de software? Ubiquitous Language (Linguagem Onipresente) Bounded Context (Contexto Delimitado) DDD é só para OOP? Links Citados: Infográfico sobre DDD (LeanPub) Livro do Eric Evans de Domain Driven Design Livro do Scott Millett Referência do DDD escrito pelo próprio Evans Domain Driven Design Quickly, InfoQ Participantes: Abner das Dores - @abnerdasdores Giovanni Bassi - @giovannibassi Heber Pereira - @heberortiz Thiago Holder - @thiagoholder Vinicius Quaiato - @vquaiato Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 – creativecommons.org/licenses/by/3.0

Carl and Richard talk to Julie Lerman and Steve Smith about the fundamentals of Domain Driven Design (DDD). Julie and Steve have collaborated on a very popular Pluralsight course about DDD that has made the methodology more approachable for more people. The conversation digs into the fact that DDD has been around for more than a decade, but hasn't caught on near as much as it should - and why is that? There's at least one alphabet soup moment: What about DDD, BDD, TDD, PDD, ADDDD and SJDD? Listen to the show for definitions of these acronyms and more!Support this podcast at — https://redcircle.com/net-rocks/donations

Carl and Richard talk to Julie Lerman and Steve Smith about the fundamentals of Domain Driven Design (DDD). Julie and Steve have collaborated on a very popular Pluralsight course about DDD that has made the methodology more approachable for more people. The conversation digs into the fact that DDD has been around for more than a decade, but hasn't caught on near as much as it should - and why is that? There's at least one alphabet soup moment: What about DDD, BDD, TDD, PDD, ADDDD and SJDD? Listen to the show for definitions of these acronyms and more!Support this podcast at — https://redcircle.com/net-rocks/donations

Panel Jaim Zuber (twitter Sharp Five Software) Pete Hodgson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Ben Scheirman (twitter github blog NSSreencast) Discussion 01:32 - Model View Controller (MVC) and Model View Presenter (MVP) Ruby on Rails Model View ViewModel (MVVM) MFC Knockout.js 14:20 - Implementing MVC in iOS Apps 16:46 - Designing Models Alistair Cockburn: Hexagonal Architecture Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans Ruby Rogues Episode #78: Hexagonal Rails with Matt Wynne and Kevin Rutherford Ruby Rogues Episode #61: Domain Driven Design (DDD) with David Laribee 28:32 - Models and the Controller Notifications 31:00 - Key-Value Observing (KVO) 35:48 - Delegates and Blocks Picks Mattt Thompson: Key-Value Observing (Pete) Alistair Cockburn: Hexagonal Architecture (Pete) Saul Mora - Design Patterns for Mobile Apps (Pete) New Spring: The Novel (Wheel of Time) by Robert Jordan (Chuck) Freelancing Q&A (Chuck) Next Week OS X Transcript PETE: I can't believe I beat Ben Scheirman today. CHUCK: With a stick? PETE: No, he's in the wrong state for that. CHUCK: Hey everybody and welcome to episode 37 of the iPhreaks Show. This week on our panel we have Jaim Zuber. JAIM: Hello from Minneapolis, where it's a balmy 4°. CHUCK: Pete Hodgson. PETE: You just totally stole my thunder. I was going to complain about being cold in San Francisco, but it's a lot warmer than that. Hello from not-so-frigid San Francisco. CHUCK: How cold is it in San Francisco? PETE: [Chuckles] Like, 32°. I don't know, it feels like it's freezing, but it's probably not even 32°. Probably warmer than that, just cold for San Francisco. CHUCK: Charles Max Wood from DevChat.tv and it's also 4° here. PETE: Okay, I'll stop complaining. JAIM: Really? Or is it just dry cold? CHUCK: Yeah, it's just dry cold here, too. We did get some snow. JAIM: There we go. PETE: It all makes sense now. JAIM: A little bit nicer. CHUCK: Yeah. Gives you something to do – go shovel snow, go skiing – we're making people jealous now, I'm sure. PETE: I think I've been here once in San Francisco when it snowed, and it was like two or three flakes on the top of Twin Peaks, which is like the only really tall bit of San Francisco, and people drove their cars up there in the middle of the night to see these snowflakes fall [chuckles]. But it wasn't like snowball fights; it was like four snowflakes. It was really exciting; it made my year. No skiing that year for us at San Francisco. CHUCK: Oh, come on. Alright. Anyway, so today on our [inaudible] we have MVC. JAIM: Alright, we're talking MVC – an MVC extravaganza of sorts, I think. CHUCK: Yup. [Chuckles] PETE: Maybe we should start off with a definition. CHUCK: [Chuckles] A definition. Thanks, Josh. JAIM: That might take the entire episode, I think. PETE: With MVC, I always get really confused. So I know what MVC stands for: Model-View-Controller. And I kind of understand the principles quite well. But what I don't get is the difference between MVC and MVP, and then it gets really confusing when you start talking about some of the other things out there. This is a long shot. Do either of you two know the difference between MVC and MVP? Because I definitely could not answer that if I have to save my life. CHUCK: I have a very vague idea of what it means, so I'm not even going to venture to try because I'll probably get it wrong. One thing that I can say, though is that I've come to iOS programming from a very strong Rails background, and MVC in Rails and MVC in iOS are not the same. JAIM: Yup. CHUCK: I tend to think of iOS as more of an MVVM, because –. JAIM: I forgot about that one. CHUCK: The controller acts more like a view model or a view controller than it does, you know, a full-on controller.

Panel Jaim Zuber (twitter Sharp Five Software) Pete Hodgson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Ben Scheirman (twitter github blog NSSreencast) Discussion 01:32 - Model View Controller (MVC) and Model View Presenter (MVP) Ruby on Rails Model View ViewModel (MVVM) MFC Knockout.js 14:20 - Implementing MVC in iOS Apps 16:46 - Designing Models Alistair Cockburn: Hexagonal Architecture Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans Ruby Rogues Episode #78: Hexagonal Rails with Matt Wynne and Kevin Rutherford Ruby Rogues Episode #61: Domain Driven Design (DDD) with David Laribee 28:32 - Models and the Controller Notifications 31:00 - Key-Value Observing (KVO) 35:48 - Delegates and Blocks Picks Mattt Thompson: Key-Value Observing (Pete) Alistair Cockburn: Hexagonal Architecture (Pete) Saul Mora - Design Patterns for Mobile Apps (Pete) New Spring: The Novel (Wheel of Time) by Robert Jordan (Chuck) Freelancing Q&A (Chuck) Next Week OS X Transcript PETE: I can’t believe I beat Ben Scheirman today. CHUCK: With a stick? PETE: No, he’s in the wrong state for that. CHUCK: Hey everybody and welcome to episode 37 of the iPhreaks Show. This week on our panel we have Jaim Zuber. JAIM: Hello from Minneapolis, where it’s a balmy 4°. CHUCK: Pete Hodgson. PETE: You just totally stole my thunder. I was going to complain about being cold in San Francisco, but it’s a lot warmer than that. Hello from not-so-frigid San Francisco. CHUCK: How cold is it in San Francisco? PETE: [Chuckles] Like, 32°. I don’t know, it feels like it’s freezing, but it’s probably not even 32°. Probably warmer than that, just cold for San Francisco. CHUCK: Charles Max Wood from DevChat.tv and it’s also 4° here. PETE: Okay, I’ll stop complaining. JAIM: Really? Or is it just dry cold? CHUCK: Yeah, it’s just dry cold here, too. We did get some snow. JAIM: There we go. PETE: It all makes sense now. JAIM: A little bit nicer. CHUCK: Yeah. Gives you something to do – go shovel snow, go skiing – we’re making people jealous now, I'm sure. PETE: I think I've been here once in San Francisco when it snowed, and it was like two or three flakes on the top of Twin Peaks, which is like the only really tall bit of San Francisco, and people drove their cars up there in the middle of the night to see these snowflakes fall [chuckles]. But it wasn’t like snowball fights; it was like four snowflakes. It was really exciting; it made my year. No skiing that year for us at San Francisco. CHUCK: Oh, come on. Alright. Anyway, so today on our [inaudible] we have MVC. JAIM: Alright, we’re talking MVC – an MVC extravaganza of sorts, I think. CHUCK: Yup. [Chuckles] PETE: Maybe we should start off with a definition. CHUCK: [Chuckles] A definition. Thanks, Josh. JAIM: That might take the entire episode, I think. PETE: With MVC, I always get really confused. So I know what MVC stands for: Model-View-Controller. And I kind of understand the principles quite well. But what I don’t get is the difference between MVC and MVP, and then it gets really confusing when you start talking about some of the other things out there. This is a long shot. Do either of you two know the difference between MVC and MVP? Because I definitely could not answer that if I have to save my life. CHUCK: I have a very vague idea of what it means, so I'm not even going to venture to try because I’ll probably get it wrong. One thing that I can say, though is that I've come to iOS programming from a very strong Rails background, and MVC in Rails and MVC in iOS are not the same. JAIM: Yup. CHUCK: I tend to think of iOS as more of an MVVM, because –. JAIM: I forgot about that one. CHUCK: The controller acts more like a view model or a view controller than it does, you know, a full-on controller.

Kerry and Rinat answer listener questions about code syntax, differences between event sourcing and relational storage, and concrete examples of Domain-Driven Design (DDD) concepts. Along the way, your questions lead them to questioning themselves and to consider an alternate approach.

Kerry and Rinat introduce the Actor in the Actor Model of Computation. They wonder if the Actor’s embodiment of communication (via messaging) may simplify the way that they reason about and implement their solutions. They discuss this potential use of the Actor Model in the context of their current usage of Domain-Driven Design (DDD), Application […]

The Rogues talk domain driven design (DDD) with David Laribee.

The Rogues talk domain driven design (DDD) with David Laribee.

The Rogues talk domain driven design (DDD) with David Laribee.