Podcasts about domain driven design

"Un bon dev c'est un dev fainéant" Le D.E.V de la semaine est Frédéric Najman, CTO as a Service et Tech Evangeliste @ Xano. Frédéric explore l'impact des technologies no-code et low-code sur le développement de logiciels, ainsi que l'intégration de l'IA. En traitant de l'inquiétude courante parmi les développeurs, Frédéric souligne que ces outils sont en fait des facilitateurs qui enrichissent leurs compétences, plutôt que de les rendre obsolètes. Avec plusieurs exemples d'entreprises adoptant ces technologies, il incite les développeurs à embrasser ces changements, amorçant un avenir prometteur pour le secteur.Chapitrages00:00:53 : Introduction au No-Code00:01:42 : Intégration du No-Code00:03:12 : Découverte du No-Code00:07:29 : Évolution des Outils No-Code00:09:00 : Impact en Entreprise00:16:21 : Rôle du Développeur00:17:14 : Sécurité et No-Code00:30:11 : Collaboration entre IT et Métiers00:35:04 : Peur des Développeurs00:40:45 : Évolution du Métier de Développeur00:48:49 : Avenir du Code et Intelligence Artificielle00:52:11 : Conclusion et Perspectives Liens évoqués pendant l'émission The singularity is nearerFall in love with the problem not the solutionThe pragmatic programer Domain-Driven Design &ndash Eric Evans **La cybersécurité, c'est l'affaire de tous ! ** Et si un simple clic pouvait compromettre toute votre entreprise ? Avec Riot, testez la vigilance de vos équipes grâce aux simulations d'attaques de phishing, et formez-les en continu avec Albert, le coach cyber qui les sensibilise directement sur Slack et Teams. Exclusif pour les auditeurs d'If This Then Dev : bénéficiez de 20% de réduction pendant un an avec le code IFTTD sur tryriot.com. Ne laissez pas une faille humaine devenir votre plus grande menace. 🎙️ Soutenez le podcast If This Then Dev ! 🎙️ Chaque contribution aide à maintenir et améliorer nos épisodes. Cliquez ici pour nous soutenir sur Tipeee 🙏Archives | Site | Boutique | TikTok | Discord | Twitter | LinkedIn | Instagram | Youtube | Twitch | Job Board |Distribué par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 22/03 a 28/03.

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 22/03 a 28/03.

Software isn't always about rapid iteration. Sometimes, the real challenge lies in carefully assessing the existing environment. Chris Salvato, a Senior Staff Engineer at Shopify, believes that spending time in the “problem space” is vital for any long-lived application. Rather than diving immediately into controllers and tests, he begins by talking to everyone who interacts with the code—engineers, product owners, even directors who oversee strategy. This approach reveals hidden friction points that rarely come to light in larger, more formal meetings.When code grows organically over years, a range of issues emerges. Small workarounds might accumulate, new features can overlap with older ones, and domain boundaries become murky. Chris suggests mapping these overlaps through in-depth conversations so the team can pinpoint what genuinely obstructs productivity. He emphasizes that many developers may focus on surface fixes—updating a library here, renaming a class there—without acknowledging underlying confusion in the domain model itself. Removing extraneous code, clarifying domain entities, and aligning the team's understanding can drastically reduce missteps.An interesting aspect of Chris's method is his view of “developer paradise.” A codebase reaches this state when new contributors can navigate it with minimal help. Instead of sifting through endless documentation or complex wikis, they can figure out how classes, modules, and services connect simply by reading the code. Chris notes that achieving this often involves pruning unnecessary files or responsibilities. The end result is software that “self-documents,” easing onboarding and reducing reliance on external explanations.The conversation also touches on how large language models (LLMs) fit into the puzzle. Many organizations see AI-driven coding assistants as a way to accelerate development. Chris agrees they have potential, yet highlights a critical requirement: the code must be well-organized. If the system is sprawling and inconsistent, these tools may only add confusion. Lean, carefully segmented projects let both people and AI more effectively track what's happening under the hood.Reducing code bloat leads naturally to discussions about prioritizing. Chris encourages teams not to tackle every annoyance at once. He references the importance of framing a unifying question, such as “Which feature or aspect of the app causes the greatest confusion among team members?” Spending too little time on this question, he warns, results in half-hearted improvements that eventually revert back to chaos. By contrast, devoting a few dedicated sprints—guided by thoughtful one-on-one interviews—can create lasting changes that set the entire codebase on a better trajectory.One intriguing theme is how personal growth ties into organizational impact. Chris acknowledges that developers often switch companies every few years, which might discourage them from investing deeply in a legacy codebase they won't maintain long-term. Yet taking the lead in clarifying domain logic or reorganizing outdated sections is a skill-building opportunity. Future employers also notice engineers who can transform messy architectures into clear, future-friendly systems. In that sense, there's a mutual benefit: the company gains maintainable software, while the developer acquires project leadership experience.The idea of “sitting in the problem space” resonates throughout Chris's remarks. He encourages engineers to resist the reflex to propose solutions too early. Instead, they should keep asking why a particular annoyance or bug persists. Is it a symptom of a misaligned feature set, or is it rooted in limited domain knowledge among contributors? By reframing those frustrations as questions about responsibilities, the team often discovers simpler fixes than a heavy-handed rewrite. Conversely, where deeper rewrites are indeed warranted, Chris believes it's best for the team to see that direction as unanimous rather than dictated from the top.Long-standing software also carries emotional baggage. People might have strong feelings about how something “ought” to be done, or they may have encountered recurring hurdles. Chris advocates using one-on-one conversations to let these concerns surface naturally, free from the pressure of group settings where quieter voices might hold back. Once everyone's perspective is heard, common threads become clearer, enabling the team to converge on a smaller list of genuinely important tasks. When the group reconvenes, the sense of shared purpose helps unify efforts in a way that scattered brainstorming rarely achieves.The conversation also highlights resourceful domain modeling, which draws some inspiration from the microservices world but doesn't necessarily require the code to be broken up into tiny services. Instead, Chris suggests that well-defined boundaries within a monolith can deliver comparable clarity—if the team respects those boundaries. He points to examples like Stripe or reading materials on Domain-Driven Design to show how cohesive object structures can help avoid big architectural hurdles.His closing thoughts revolve around long-term sustainability. Even if an engineer isn't planning to remain on a project indefinitely, they can leave a meaningful legacy by clarifying crucial parts of the code, championing simpler naming conventions, and encouraging more open dialogue among team members. The impact, Chris notes, goes beyond the immediate project: every person who touches that code later benefits from these improvements, often for years to come.Time-Stamped Highlights[00:00:00] Welcome and Well-Maintained Software:Robby opens by asking Chris about foundational traits of dependable, long-lasting codebases.[00:00:58] Defining “Well Maintained”:They explore how clear conventions and minimal bloat not only reduce confusion but also prolong the life of a system.[00:01:28] LLMs and Context Windows:Chris delves into why large codebases challenge AI-driven coding assistants—and how trim, well-modeled systems sidestep this pitfall.[00:02:00] Joining Shopify and Facing Legacy Systems:Chris recalls his early days at Shopify, realizing that older Rails apps demanded a more structured method of discovery.[00:03:08] Concept of “Developer Paradise”:He shares his perspective on how removing unneeded documentation and extraneous complexity makes daily development more enjoyable.[00:05:32] Framework for Tackling Old Code:Chris outlines his signature approach: booking numerous 1-on-1 meetings to gather honest feedback from stakeholders before touching the code.[00:07:15] Finding High-Leverage Problems:Robby and Chris discuss distilling this feedback into a shortlist of real bottlenecks that the team can tackle together.[00:15:00] From Problem Space to Solutions:They spotlight the value of framing a single unifying question—like “How do we reduce confusion?”—to keep everyone working toward the same outcome.[00:20:07] Balancing Personal Goals and Company Needs:Chris underlines how aligning individual ambitions with business objectives fosters commitment to sustained improvement.[00:32:00] Long-Term Value and Leadership:Closing out, Robby and Chris consider how short-tenure engineers can leave a lasting impact by helping a team focus on its biggest pain points.Resources & MentionsShopifyRuby on RailsChris's GitHubChris's LinkedInChris's Twitter/XThe One Thing by Gary KellerTitan: The Life of John D. Rockefeller, Sr. by Ron ChernowMartin Fowler on MicroservicesDomain-Driven Design

Event Sourcing: Ein Deep Dive mit Golo RodenSpeziell beim Debuggen stellen wir uns oft die Frage “Wie kam dieser Datensatz nun in diesen Zustand?”. Nachvollziehbarkeit ist da oft schwer. Wenn man Glück hat, gibt es irgendwo ein Log. Wenn man Pech hat, hat man nach der erfolglosen Log-Suche ein neues Ticket, um ein Log einzubauen. Wäre es nicht irgendwie cool, alle Zustandsänderungen zu protokollieren bzw. zu speichern? Oder noch besser: Dieses Verhalten als First-Class-Konzept in meiner App zu behandeln?Wenn man das Ganze weiter denkt, landet man oft beim Thema “Event Sourcing”. Event … wat?In dieser Podcast-Episode machen wir mal einen Deep Dive ins Thema Event Sourcing. Wir klären, was Event Sourcing eigentlich ist, welches Problem es eigentlich löst, wie technische Implementierungen aussehen können, was Command Query Responsibility Segregation (CQRS) und Domain Driven Design damit zu tun haben, wann man doch lieber Abstand von Event Sourcing halten sollte und welche Tools und Datenbanken dich dabei unterstützen.Bonus: Wie viele Stadtbibliotheken nutzen eigentlich Event Sourcing?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

https://bit.ly/Intro_Event_Sourcing_Podcast Practical Intro to Event Sourcing WorkshopNew Small Talk interview with Oskar Dudycz to present his upcoming remote workshop Practical Introduction to Event Sourcing.We'll talk about Event Sourcing, Domain-Driven Design and how they can help keep track of all the business facts without losing a single piece of business information while answering tomorrow's questions and challenges.Oskar will help us get an overview of how the workshop will actually work and what we are gonna get out of it - our goal is always to provide some tools and ideas you can start implementing in your work from day one after the class.

https://bit.ly/Intro_Event_Sourcing_Podcast Practical Intro to Event Sourcing WorkshopNew Small Talk interview with Oskar Dudycz to present his upcoming remote workshop Practical Introduction to Event Sourcing.We'll talk about Event Sourcing, Domain-Driven Design and how they can help keep track of all the business facts without losing a single piece of business information while answering tomorrow's questions and challenges.Oskar will help us get an overview of how the workshop will actually work and what we are gonna get out of it - our goal is always to provide some tools and ideas you can start implementing in your work from day one after the class.

In dieser Folge spricht Carsten mit Jan Schwake von Interhyp über die grundlegende Transformation der IT- und Datenlandschaft des Unternehmens.

Новый выпуск подкаста, записан в шумной переговорке в перерыве между конференциями. Вместе с Алексеем Мерсоном, developer advocate в продукте SAGE Т-Банк, обсуждаем DDD. Хвалим новую книгу Хононова и не только . Eric Evans — Domain-Driven Design: Tackling Complexity in the Heart of Software Эрик Эванс — Предметно-ориентированное проектирование Vaughn Vernon — Implementing Domain-Driven Design Вон Вернон — Реализация методов предметно-ориентированного проектирования Martin Fowler — Patterns of Enterprise Application Architecture Мартин Фаулер, Дейвид Райс, Мэттью Фоммел — Шаблоны корпоративных приложений Vlad Khononov — Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy Влад Хононов — Изучаем DDD-предметно-ориентированное проектирование Участники @golodnyj Алексей Мерсон Telegram канал VK группа Яндекс Музыка iTunes подкаст Поддержи подкаст

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview here:https://gotopia.tech/episodes/331Maciej «MJ» Jedrzejewski - Tech Agnostic Architect & Author of "Master Software Architecture"Artur Skowroński - Head of Java & Kotlin Engineering at VirtusLab & Editor of "JVM Weekly"RESOURCESMJhttps://github.com/meaboutsoftwarehttps://www.linkedin.com/in/jedrzejewski-maciejhttps://www.fractionalarchitect.ioArturhttps://x.com/ArturSkowronskihttps://www.linkedin.com/in/arturskowronskihttps://www.jvm-weekly.comDESCRIPTIONThis conversation explores the evolution and complexities of software architecture, from early programming experiences to advanced design principles.It highlights practical gaps and the value of self-publishing, consulting, and addressing architectural pitfalls. Trends like microservices, serverless computing and AI are examined critically, emphasizing their limitations and supportive roles.Recommendations for further reading include Gregor Hohpe's "Software Architect Elevator", Martin Kleppmann's "Designing Data-Intensive Applications", "Software Architecture: The Hard Parts" and Nick Tune's "Architecture Modernization," offering deep insights into effective software practices.RECOMMENDED BOOKSMaciej «MJ» Jedrzejewski • Master Software Architecture • https://leanpub.com/master-software-architectureGregor Hohpe • Platform Strategy • https://amzn.to/4cxfYdbGregor Hohpe • The Software Architect Elevator • https://amzn.to/3F6d2axMartin Kleppmann • Designing Data-Intensive Applications • https://amzn.to/3mk2RojFord, Richards, Sadalage & Dehghani • Software Architecture: The Hard Parts • https://amzn.to/3QeMgjRNick Tune & Jean-Georges Perrin • Architecture Modernization • https://amzn.to/4b5ASiNSam Newman • Monolith to Microservices • https://amzn.to/2Nml96EVaughn Vernon & Tomasz Jaskula • Strategic Monoliths & Microservices • https://amzn.to/3AcUscjBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

This interview was recorded at GOTO Amsterdam for GOTO Unscripted.http://gotopia.techRead the full transcription of this interview here:https://gotopia.tech/articles/326Susanne Kaiser - Independent Tech Consultant & Author of "Architecture for Flow"James Lewis - Software Architect & Director at ThoughtworksRESOURCESSusannehttps://mastodon.social/@suksrhttps://twitter.com/suksrhttps://www.linkedin.com/in/susannekaiser1https://susannekaiser.netJameshttps://twitter.com/boicyhttps://linkedin.com/in/james-lewis-microserviceshttps://github.com/boicyhttps://www.bovon.orgDESCRIPTIONSusanne Kaiser, an expert tech consultant, shares her secrets for integrating Wardley mapping, team topologies and domain-driven design to streamline value delivery and boost team effectiveness. The discussion with James Lewis highlights the power of hands-on collaboration, the value of understanding the purpose behind tools, and practical tips for breaking down silos and overcoming analysis paralysis. Tune in to discover how these cutting-edge techniques can transform your approach to organizational change and team dynamics.RECOMMENDED BOOKSSusanne Kaiser • Adaptive Systems With Domain-Driven Design, Wardley Mapping & Team Topologies • https://amzn.to/3XTmNCcSimon Wardley • Wardley Mapping, The Knowledge • https://amzn.to/3XQEeDuSimon Wardley • Wardley Maps • https://amzn.to/45U8UprMatthew Skelton & Manuel Pais • Team Topologies • http://amzn.to/3sVLyLQHeidi Helfand • Dynamic Reteaming • https://amzn.to/3Fvu5BAEric Evans • Domain-Driven Design • https://amzn.to/3tnGhwmGregor Hohpe • Platform Strategy • https://amzn.to/4cxfYdbBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Diese Episode beginnt die Reise durch ein vollständiges Beispiel und zeigt , wie die verschiedenen Techniken wie Event Storming und strategisches Design zusammen wirken, um den Aufbau von Anwendungen zu unterstützen. Das zeigt, wie man mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können. In dieser Episode geht es um taktisches Design, CQRS, Event Sourcing und hexagonale Architektur. Links Training Domain-driven Design saniert Legacy Folien Taktisches Domain-driven Design (DDD) Taktisches Domain-Driven Design mit Java und jMolecules mit Oliver Drotbohm Folgen zu Architecture Management Events, Event Sourcing und CQRS Video zu Kafka als Datenbank-Monolith Christian Stettler: Domain Events vs. Event Sourcing - Weshalb Domain Events und Event Sourcing nicht vermischt werden sollten Vaughn Vernon about Ports and Adapters and DDD

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Diese Episode beginnt die Reise durch ein vollständiges Beispiel und zeigt , wie die verschiedenen Techniken wie Event Storming und strategisches Design zusammen wirken, um den Aufbau von Anwendungen zu unterstützen. Das zeigt, wie man mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können. In dieser Episode geht es um die Elemente von Strategic Design wie Bounded Context. In einer zweiten Episode wird es um taktisches Design gehen. Links Folien Bert Jan Schrijver about Generic or Specific? Domain Story Telling mit Henning Schwentner und Stefan Hofer Wir bauen eine Software-Architektur - Struktur der Lösung Technischer Kontext und fachliche Aufteilung - iSAQB Advanced Beispielaufgabe Bounded Context - Was ist das genau? Team Topologies Team Topologie in der Praxis mit Kim Nena Duggen

"Pour réussir le Run, il faut réussir le Delivery. Pour réussir le Delivery, il faut réussir le Discovery. Pour qu'une application s'épanouisse en Prod, ça doit être pensé dès le premier jour 1 du Projet voire même dès la vente du projet !"Julien Lefebvre, Lead Product et Architect chez exFabrica nous partage comment éviter les échecs Projets, qui sont légion.Accès rapide :02:10 - Le motto d'Ex-Fabrica, « Shift left » sur le cycle de vie produit06:00 - Quel % des projets IT échouent ?10:30 - 50% des fonctionnalités IT ne sont pas utilisés, comment on peut éviter ça ?14:38 - Rôles de l'architecte, comment critères de succès et architecture interagissent ?20:35 - Qualité logicielle et critères d'évaluation25:20 - Comment parler architecture en avant-vente ?31:04 - Domain Driven Design : langage utilisateur et Design System39:30 - Trouver la bonne solution “dérisquée” à une idée43:17 - L'impact énorme des LLM49:45 - MVP et story mapping53:40 - Comment on gère l'intelligence collective57:18 - Identifier les vrais points de douleur : contournement59:50 - Mesurer la qualité des développements et la productivité : les points de complexité et la garantie très longue1:04:05 - The infinite game de Simon Sinek, les effets Ikea et Docteur House1:09:30 - Exfabrica, une ESN différente1:20:40 - Travailler avec des cultures différentesLe meilleur conseil : "Fais du mieux que tu peux"Les recommandations : Hyperion de Dan Simons & Sa liste des films et séries recommandésL'interview d'Aimery dans On part en Prod, le podcast de Julien Lefebvre Hébergé par Acast. Visitez acast.com/privacy pour plus d'informations.

In dieser Folge widmen wir uns sehr tiefgehend dem Thema Domain-Driven Design. Falls dir das Thema noch neu ist, hör doch vorher in Folge 57 rein, „DDD, Event Sourcing und CQRS mit Golo Roden“.Domain-Driven Design, kurz DDD, ist kein neues Phänomen. In der Literatur existiert es bereits seit über 20 Jahren, aber gerade in der praktischen Anwendung hakt es noch häufig. Oftmals werden verschiedene Definitionen und Vorstellungen vermischt und Methodik mit Implementierung verwechselt.Um mit all diesen Vorurteilen und Missverständnissen aufzuräumen, haben wir uns Stefan Priebsch ins Studio eingeladen. Gemeinsam diskutieren wir nicht nur die Geschichte von DDD, sondern auch den aktuellen Stand und lauschen seinen Erfahrungen aus 20 Jahren Praxis zu diesem Thema.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTubeMusik: Hanimo

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereNick Tune - Author of "Architecture Modernization" & Staff Engineer at PayFitEduardo da Sliva - Independent Consultant on Socio-technical Systems, Architecture & Leadership ModernizationRESOURCESNickhttps://hachyderm.io/@nick_tunehttps://www.linkedin.com/in/nick-tunehttps://nick-tune.mehttps://medium.com/nick-tune-tech-strategy-blogEduardohttps://x.com/emgsilvahttps://mastodon.social/@eduardodasilvahttps://www.linkedin.com/in/emgsilvahttps://github.com/emgsilvahttps://esilva.nethttps://esilva.net/ametDESCRIPTIONEduardo da Silva interviews Nick Tune about his book "Architecture Modernization." Nick Tune shares his motivations for writing the book, emphasizing the socio-technical alignment of software, strategy, and structure. They discuss the importance of business objectives, the role of Architecture Modernization Enabling Teams (AMET), and practical steps to initiate and sustain modernization efforts. Nick Tune also highlights the continuous nature of modernization and the need for organizations to adapt and learn over time.The conversation provides valuable tips for effectively approaching architecture modernization and ensuring long-term success.RECOMMENDED BOOKSNick Tune & Jean-Georges Perrin • Architecture ModernizationScott Millett & Nick Tune • Patterns, Principles, and Practices of DDDMatthew Skelton & Manuel Pais • Team TopologiesFord, Richards, Sadalage & Dehghani • Software Architecture: The Hard PartsSimon Brown • Software Architecture for Developers Vol. 2Woods, Erder & Pureur • Continuous Architecture in PracticeTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Ruben Casas discusses software migrations at scale, understanding different migration patterns, making critical decisions on whether a full rewrite is necessary, and more. This episode covers all the essentials you need to navigate your next big software transformation. Links https://www.linkedin.com/in/ruben-casas-17100383 github.com/infoxicator https://www.infoxicator.com/ https://x.com/Infoxicador https://www.youtube.com/c/RubenCasas We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)

Когда говорят о качестве кода, часто упоминают DDD. Но реально ли так сильны эти три буквы?Спасибо всем, кто нас слушает. Ждем Ваши комментарии.Бесплатный открытый курс "Rust для DotNet разработчиков": https://www.youtube.com/playlist?list=PLbxr_aGL4q3S2iE00WFPNTzKAARURZW1ZShownotes: 00:00:00 Вступление00:04:20 Что такое DDD?00:13:20 На сколько сильно программист должен знать предметную область?00:36:20 Стратегические паттерны DDD00:41:00 Самое главное - единый язык00:44:00 Инфраструктурная команда и DDD00:52:00 Ограниченный контекст01:01:00 Аггрегат01:06:00 Богатая и анемичная модель01:23:00 Value Object01:29:00 Entity01:32:00 Application Service01:46:00 Repository02:03:00 Если в бизнесс процессах хаос?Ссылки:- https://habr.com/ru/articles/580972/ : Та самая книга- https://youtu.be/CR9mLGN9jh0 : Алексей Мерсон — Domain-driven design: рецепт для прагматикаВидео: https://youtube.com/live/WJy1zZ3YbgU Слушайте все выпуски: https://dotnetmore.mave.digitalYouTube: https://www.youtube.com/playlist?list=PLbxr_aGL4q3R6kfpa7Q8biS11T56cNMf5Twitch: https://www.twitch.tv/dotnetmoreОбсуждайте:- Telegram: https://t.me/dotnetmore_chatСледите за новостями:– Twitter: https://twitter.com/dotnetmore– Telegram channel: https://t.me/dotnetmoreCopyright: https://creativecommons.org/licenses/by-sa/4.0/

What do Domain-Driven Design and event sourcing have to do with each other? Everything! Carl and Richard chat with Anita Kvamme about her experiences applying DDD, and specifically event storming, to developing applications using event sourcing. Anita talks about building applications that have many sources of events—from users and elsewhere—and needing to manage that complexity without slowing down development. Event sourcing also means keeping a source of the truth - all events leading up to a practical business benefit. And that can be hugely helpful in analytics as well!

What do Domain-Driven Design and event sourcing have to do with each other? Everything! Carl and Richard chat with Anita Kvamme about her experiences applying DDD, and specifically event storming, to developing applications using event sourcing. Anita talks about building applications that have many sources of events—from users and elsewhere—and needing to manage that complexity without slowing down development. Event sourcing also means keeping a source of the truth - all events leading up to a practical business benefit. And that can be hugely helpful in analytics as well!

SummaryIn this conversation, Vaughn Vernon and Udi Dahan discuss various topics related to software architecture, including service-oriented architecture (SOA), event-driven architecture, and sagas. They emphasize the importance of using the right architectural styles and patterns in the right places, rather than over-applying or misapplying them. They also discuss the role of patterns in software development and the need for a common language to facilitate communication among developers. Additionally, they explore the strengths and weaknesses of event-driven architecture and the misconceptions around API-first design. Finally, they delve into the concept of sagas as a way to handle complex business processes and policies.TakeawaysUse the right architectural styles and patterns in the right placesPatterns are important for facilitating communication among developersEvent-driven architecture should not be over-applied or misappliedAPI-first design should consider the actual business processes and not just CRUD operationsSagas can be a useful technique for handling complex business processes and policiesChapters00:00 Introduction and Background04:21 Understanding Service-Oriented Architecture (SOA)09:36 The Role of Patterns in Software Development18:17 Exploring Event-Driven Architecture35:07 The Concept of SagasUdi Dahan is one of the world's foremost experts on Service-Oriented Architecture and Domain-Driven Design and also the creator of NServiceBus, the most popular service bus for .NET. Hosted on Acast. See acast.com/privacy for more information.

Zostać CTO i móc samodzielnie podejmować wszystkie decyzje techniczne w projekcie i mieć ostateczne zdanie na każdy temat... Taka wizja przyszłości w nawet średniej wielkości organizacji często nie ma jednak zbyt wiele wspólnego z rzeczywistością. Na czym więc polega rola Chief Technology Officera i ile jest w niej realnie technologii?W wiadomościach od was, na równi z tematami o architekturę, EventStorming czy Domain-Driven Design przewijają się bardo często pytania o dalszą karierę. W jakim kierunku się rozwijać, czy wiązać dalsze plany w IT ze ścieżką stricte techniczną i zostać np. architektem, czy może całkowicie skręcić w stronę managementu i kierowania zespołem czy projektem... W tym wszystkim pytania związane z funkcją i rolą CTO padały chyba najczęściej. Tak więc temat w końcu zagościł na antenie.Dziś zapraszam Cię na rozmowę z Danielem Owsiańskim, na tematy związane właśnie z funkcją Chief Technology Officera i zarządzania technologią w firmie. Wybór gościa był jak zwykle nieprzypadkowy — Daniel pełni rolę CTO w Volt.io, gdzie mamy okazję na codzień współpracować.Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz aktualne oferty pracy.Zapraszam Cię także do odwiedzenia bloga Daniela, owsianski.com, który ostatnio pojawił się w sieci.

Wiele osób chciałoby przy każdym projekcie pracować w green-fieldzie i móc wszystkie decyzje podejmować samodzielnie. Rzeczywistość jest jednak zwykle całkowicie inna, musimy żyć z odziedziczonym kodem i zaprojektowanym modelem. Taki green-field, w którym można zacząć projektować i wdrażać nowy model i techniki DDD, można jednak sobie wykroić.Wspólnie z Marcinem Markowskim rozmawiamy dziś o technikach Bubble Context, Autonomous Context i Legacy As Exposed Service Erica Evansa, dzięki którym można zacząć refaktoryzację legacy. Z mniejszym lub większym związaniem z legacy, w zależności od potrzeb i możliwości w projekcie.W dzisiejszej rozmowie:na czym polegają techniki Bubble i Autonomous Context,kiedy warto, a kiedy nie, korzystać z ich możliwości,wykorzystaniu istniejących danych w nowym modelu domenowych,ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,współpracy w zespole przy wdrażaniu takich technik.Materiały dodatkowe:Artykuł Getting Started with DDD when surrounded by legacy systems Erica Evans, 2013

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.

SummaryIn this podcast episode, Vaughn and Mark Planagumà discuss various aspects of data strategies and the implementation of Data Mesh. Mark shares his background in data engineering and his experience in building data platforms for different companies. They explore the use of Domain-Driven Design in data strategies and the role of contracts in data architecture. Mark explains the concept of Data Mesh and how it shifts the focus from centralized data warehouses to domain-driven, decentralized data products. They also discuss the implementation of data governance and automation, the influence of operational software architectures on data strategies, and the design of a semantic layer in a Data Mesh. The conversation explores the maturity in operational and analytical architecture, the influence of Domain-Driven Design on Data Mesh, the tooling required for Data Mesh, the future of analytics, challenges with AI and metadata, and where to learn more about Data Mesh.TakeawaysDomain-Driven Design can be applied to data strategies to organize data by domains and enable domain owners to take responsibility for their data.Data Mesh is a paradigm shift that emphasizes decentralized, domain-driven data products instead of centralized data warehouses.Contracts play a crucial role in data architecture by defining the metadata and governance rules for data products.Implementing data governance and automation can help ensure the discoverability, accessibility, and reusability of data in a data mesh.Organizational structure needs to align with the principles of Data Mesh, with domain-driven teams owning and managing their data.A semantic layer in a Data Mesh helps organize and aggregate data products by domains, making it easier to discover and consume data.Operational software architectures can influence data strategies by providing the infrastructure and tooling for data products in a Data Mesh. Data is typically behind operational and application maturity, but Data Mesh is emerging to bridge the gap.Domain-Driven Design plays a significant role in shaping Data Mesh and enabling interoperability between operational and analytical systems.Existing tools like lake houses and data warehousing can be leveraged to support Data Mesh, focusing on creating interoperable data products.The future of analytics lies in improving data quality, metadata management, and leveraging AI to interact with data in a more natural and business-focused way.ChaptersPlease note these are approximate locations! We are trying new tools and hope you find this helpful.00:00 Introduction and Background05:32 Using Domain-Driven Design with Data Strategies09:20 Understanding Data Mesh11:18 The Role of Contracts in Data Architecture28:21 Influencing Organizational Structure for Data Mesh34:00 Semantic Layer Design in Data Mesh37:36 Impact of Operational Software Architectures on Data Strategies37:52 Maturity in Operational and Analytical Architecture42:30 Domain-Driven Design and Data Mesh47:08 Tooling for Data Mesh53:29 The Future of Analytics01:01:08 Challenges with AI and Metadata01:09:36 Learning More about Data MeshMarc Planagumà, is a native of Olot (Catalonia) with degrees in Telecommunications from UPC. He is a prominent figure in data engineering and governance. He serves as the Data Platform & Governance Director at Adevinta Spain, where he has spearheaded the development and implementation of Lakehouse architecture and Data Mesh paradigm, focusing on scalability, autonomy, and effective governance by design. Hosted on Acast. See acast.com/privacy for more information.

“Soft skills are always going to be those ladders for you to climb in your career, whereas your tech skills can turn into snakes, meaning you've got to start again with another skill." Jacqui Read, author of “Communication Patterns,” joins in this episode to discuss why strong communication skills are crucial for developers and technical leaders, often surpassing the importance of merely technical expertise. We delve into four key communication areas: visual communication, multimodal communication, communicating knowledge, and communicating remotely. During the discussion, Jacqui suggests several practical patterns you can immediately implement to level up your communication skills, such as knowing your audience, the big picture comes first, and perspective-driven documentation.   Listen out for: Career Journey - [00:01:40] Architecture Kata - [00:03:17] Writing Communication Patterns - [00:05:03] Importance of Soft Skills - [00:07:33] Visual Communication - [00:09:24] Visual Communication Essentials - [00:12:12] Visual Narrative - [00:17:46] Multimodal Communication - [00:21:09] Verbal & Non-Verbal Communication - [00:26:29] Encoding & Decoding - [00:29:58] Communicating Knowledge - [00:32:22] Tips for Capturing Knowledge - [00:40:14] Get Feedback Early & Just-in-Time - [00:43:05] Communicating Remotely - [00:48:59] 3 Tech Lead Wisdom - [00:54:23] _____ Jacqui Read's BioJacqui Read is an internationally-recognised solution and enterprise architect, and author of Communication Patterns: A Guide for Developers and Architects. She teaches public and private workshops and speaks at international conferences on topics such as architecture practices, technical communication, and systems design. Jacqui specialises in untangling and extracting value from data and knowledge, helping businesses to determine direction in complex environments. Her professional interests include collaborative modelling, knowledge management, Domain-Driven Design, sociotechnical architecture, and modernising enterprise architecture practices. Outside of work she enjoys gardening and strumming her ukulele while singing at the same time. Follow Jacqui: Personal Website – jacquiread.com LinkedIn – linkedin.com/in/jacquelineread Book's Website – communicationpatternsbook.com _____ Our Sponsors Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.Get a 45% discount for Tech Lead Journal listeners by using the code techlead45 for all products in all formats. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/170. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

In today's episode, we are joined by João Rosa and Trond Hjorteland, two organizational consultants with a unique point of view, who take us through the depth of Open Systems Theory, and what it means to be socio-technical practitioners, passionate about transitioning democratic organizations to fast-flowing operational models.  With many years of experience in large and complex contexts, they delve into what it means to create a collaborative and democratic organization, and how to balance mission, business outcomes, and cognitive load. Join us on this episode, as we debate the role of “purpose”, entrepreneurship, and autonomy and learn how to avoid the creation of agile bureaucracies. Tune in, and get inspired. In the conversation with Rosa and Hjorteland we started from an original question that Simone threw out at a small conference recently: how do we avoid building Agile Bureaucracies?  What does it mean to develop a business that achieves agility without having to exert total control on flows and processes? With increasingly complex and dynamic environments, it becomes pivotal for organizations to recognize and adapt to change, if not stay ahead of it and rigidities are more than dangerous - even the cultural ones. Emphasizing learnings from different methodologies like Open Systems Theory, Domain Driven Design, and Team Topologies; our guests advocate a team-centered, and democratic approach over industrial and hierarchical practices.  A unique episode to look out for.  Tune in.   Key Highlights

Welcome to another exciting episode of the Mob Mentality Show! In this edition, our guest, the remarkable John Gallagher, takes us on a journey through the intricate world of software design, focusing on the compelling theme - "Reducing Cost of Change Through Design."

Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery.Moimi gośćmi są Dariusz Pawlukiewicz i Michał Wilczyński, programiści i architekci, zaangażowani w inicjatywę DevMentors. A rozmawiamy przede wszystkim o doświadczeniach związanych z wprowadzaniem DDD do zespołów i organizacji, oraz o częstych problemach występujących w procesach poznawania domeny.Materiały dodatkowe:Domain model purity vs. domain model completeness (DDD Trilemma), wspomniany w rozmowie artykuł Vladimira KhorikovaThe failed promise of Domain-Driven Design - part 1, artykuł Sebastiana GębskiegoThe failed promise of Domain-Driven Design - part 2, kontynuacja powyższego artykułu

An independent tech consultant with over 20 years, Susanne Kaiser joins the podcast and shares her insights on what makes a robust socio-technical system. Integrating takeaways from different approaches like Wardley Mapping, Domain Driven Design, and Team topologies, she helps the listeners understand how to mold systems into ones that are adaptable to change, how to invest in the right things, and how to avoid wasting resources on things that do not make a competitive advantage.  We further touch upon topics like building in bounded contexts and unbundling the right way. This episode has an ocean of information, which can help listeners achieve better strategic awareness of their company, products, and initiatives. Grab a coffee cup and a notebook and listen.  In this episode, Susanne takes us through what it means to operate a business with a strategic perspective.  An organization's evolutionary journey goes through high levels of change and uncertainty. With insights on bounded contexts and evolution, Susanne takes us through how you can enforce modularity and cohesion among the different parts of the system, to deal with such a journey. With significant experience working as a consultant in the software development world, Susanne shares real-world examples of how organizations can create architecture and team structures that are dynamic and play to an organization's competitive advantage.   Key Highlights

"Scope" and "requirements" for software rely on a common understanding of basic concepts like "vehicles" or "names" but humans have no idea how to nail down those ideas. Join your host Squirrel and Jeffrey to find out why, and what to do about it, on this episode of Troubleshooting Agile. Links: - No Vehicles in the Park game: https://novehiclesinthepark.com - Keith Braithwaite: https://twitter.com/keithb_b - The Big Book of Concepts: https://mitpress.mit.edu/9780262632997/the-big-book-of-concepts/ - Falsehoods programmers believe about names: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ - Cynefin: https://en.wikipedia.org/wiki/Cynefin_framework - Domain Driven Design and ubiquitous language: https://en.wikipedia.org/wiki/Domain-driven_design -------------------------------------------------- Order your copy of our book, Agile Conversations at agileconversations.com Plus, get access to a free mini training video about the technique of Coherence Building when you join our mailing list. We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick first met while working together at TIM group in 2013. A decade later, they remain united in their passion for growing organisations through better conversations. Squirrel is an advisor, author, keynote speaker, coach, and consultant, helping companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: https://douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, author and speaker. You can connect with him here: https://www.linkedin.com/in/jfredrick/

What does the future of software development look like? How will AI shape software engineer jobs? In this episode of the Engineering Room podcast, Dave is joined by author, software engineer and well-known thought leader, Eric Evans. They talk about Eric's background, domain-driven design, artificial intelligence and what the next 10 years look like for the software industry with the emergence of AI.Eric wrote THE software design book that should be on every software engineer's bookshelf.xx

Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw...Bo czym właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i właściwie czemu to ma służyć? Jeśli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka.Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać.W tym odcinku rozmawiamy z Łukaszem o:hype na Domain-Driven Design i trudnościach w jego stosowaniuintuicjach, heurystykach vs. praktyki inżynieryjneanalizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczysumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycjistabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmianweryfikacji wytwarzanych w ten sposób podziałów w projekciedobrych momentach na refaktoryzację systemuMateriały dodatkowe:Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w FirstSDLab, inicjatywa projektów badawczych w zakresie projektowania oprogramowania

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.

In this episode, Michael Hibay (API Platform Architect at WSFS Bank) and Mike Amundsen (Amundsen,com, Inc.) deep dive into the topic of hypermedia, complex systems, Domain Driven Design, and generative AI. They explore the questions of what hypermedia API is, what an API affordance catalog can be, and how language models can be applied on the client's side.  Additional Sources:  Design and Build Great Web APIs: Robust, Reliable, and Resilient by Mike Amundsen I pledge to do no harm with your data by Michael Hibay 3 Ideas On AI Readiness, The Role of APIs and Developer Portals In Generative AI Systems by Kristof Van Tomme

In this podcast episode, Vaughn interviews Jacqui Read, a .NET developer turned software architect and author of the book "Communication Patterns: A Guide for Developers and Architects." Jacqui discusses the inspiration behind her book, emphasizing the importance of soft skills in conjunction with technical expertise. She highlights her experience in various domains and how she integrated diverse ideas into her work, leading to the identification of communication patterns and anti-patterns. The conversation delves into the reputation of programmers as poor communicators and the potential for improvement through Jacqui's insights.Jacqui's book covers a broad spectrum of communication, including verbal, written, non-verbal, and visual communication. Jacqui emphasizes the significance of visual communication, which constitutes a substantial portion of the book. She addresses the inclusion of illustrations, particularly discussing considerations for grayscale printing and offering links to color versions on the accompanying website. The podcast touches on sections of the book dedicated to the communication of knowledge, documentation, and the challenges of remote communication in today's distributed teams and companies.Jacqui Read is an internationally recognised solution and enterprise architect, and author of "Communication Patterns: A Guide for Developers and Architects", with hands-on experience and expertise architecting and coding software systems. She specialises in assisting businesses to create and enhance architecture practices, construct evolutionary architectures, and untangle and extract value from data and knowledge.Alongside consulting, Jacqui teaches public and private workshops and speaks at international conferences on topics such as architecture practices, technical communication, and architecture decisions. Her professional interests include collaborative modelling, knowledge management, Domain Driven Design, sociotechnical architecture, and modernising enterprise architecture practices. Outside of work she enjoys gardening and attempting to strum her ukulele and sing at the same time. Her website is https://jacquiread.com. Hosted on Acast. See acast.com/privacy for more information.

Encje domenowe to obok Value Objectów jeden z podstawowych wzorców implementacyjnych Domain-Driven Design. Mogą działać zarówno samodzielnie, jak i być częścią innych struktur, np. agregatów. Ale czym właściwie są encje i co odróżnia je od pozostałych wzorców taktycznego DDD?W telegraficznym skrócie encje to obiekty domenowe posiadające ściśle określoną tożsamość, które z jakiegoś powodu muszą być śledzone na przestrzeni czasu. Gościem dzisiejszej rozmowy jest Kamil Grzybek, który pojawił się już w Better Software Design przy okazji rozmów o modularyzacji monolitu czy testowalności oprogramowania.W tym odcinku rozmawiamy między innymi o:przeznaczeniu wzorca Entity,różnych metodach nadawania tożsamości obiektom,podziałach encji względem cykli życia w domenie,różnicach pomiędzy encjami a agregatami czy Value Objectami,mapowaniu encji domenowych na encje bazodanowe.Zapraszam!Materiały dodatkowe:Implementing Domain-Driven Design, rozdział 5 poświęcony encjom domenowymWhat Is the Hi/Lo Algorithm?, artykuł na temat algorytmu Hi/Lo do generacji identyfikatorówEntity Identity vs Database Primary KeyModular Monolith with DDD, repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych

Show Notes Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie "GaProgMan" Taylor. In this episode, I spoke with Josh Garverick about event-driven and domain-driven design, and his recently published book "Implementing Event-Driven Microservices Architecture in .NET 7". When talking about the book, he had this to say about it's target audience: "Absolutely. And one of the aims, I think for at least this book was to make sure that it's kind of applicable across a lot of different audiences, not just the folks coming in super green and just looking at it like, I've never seen this stuff before. There are some disclaimers in the beginning of the book, obviously saying, 'you should probably have at least a baseline understanding of things like domain-driven design containerization and things like that,' but we'll link out to resources to get yourself up to speed. So even if you don't have any background in that stuff, there's at least a place for you to go out and get that information and then come back and then start going through that journey." - Josh Garverick Not only is his book designed for people, regardless of where they are on their journey with .NET, but, as we'll find out in the episode, it's also filled with pragmatic lessons that developers can apply to any application that they're working on. Supporting the Show If you find this episode useful in any way, please consider supporting the show by either leaving a review (check our review page for ways to do that), sharing the episode with a friend of colleague, buying the host a coffee, or considering becoming a Patron of the show. Full Show Notes The full show notes, including links to some of the things we discussed and a full transcription of this episode, can be found at:  https://dotnetcore.show/season-6/from-self-taught-to-mvp-navigating-the-event-driven-world-with-josh-garverick/ Useful Links Josh's new book "Implementing Event-Driven Microservices Architecture in .NET 7" from Packt directly from Amazon Chaos Studio chaos engineering Josh on socials: @jgarverick on Twitter LinkedIn Supporting the show: Leave a rating or review Buy the show a coffee Become a patron Getting in touch: via the contact page joining the Discord Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend. And don't forget to reach out via our Contact page. We're very interested in your opinion of the show, so please get in touch. You can support the show by making a monthly donation on the show's Patreon page at: https://www.patreon.com/TheDotNetCorePodcast.

Software design patterns were derived from the work of architect Christopher Alexander, specifically his book A Pattern Language: Towns, Buildings, Construction. This excerpt (from episode 39) addresses a problem: most software people don't know one of Alexander's most important ideas, that of "forces". SourcesChristopher Alexander et al, A Pattern Language: Towns, Buildings, Construction, 1977.Mentioned (or that I wish I'd found a way to mention)Gamma et al, Design Patterns, 2004Eric Evans, Domain-Driven Design, 2003. I also like Joshua Kerievsky's pattern-language-like description of study groups, "Pools of Insight".Brian Marick, "Patterns failed. Why? Should we care?", 2017 (video and transcript)"Arches and Chains" (video) is a nice description of how arches work.Ryan Singer, "Designing with forces: How to apply Christopher Alexander in everyday work", 2010 (video)CreditsBy Anneli Salo - Own work, CC BY-SA 3.0, Wikipedia Commons

Farrell describes a number of distinct roles important to the development of a collaborative circle. This episode is devoted to the roles important in the early stages, when the circle is primarily about finding out what it is they actually dislike about the status quo. In order to make the episode more "actionable", I describe the roles using Christopher Alexander's style of concentrating on opposing "forces" that need to be balanced, resolved, or accommodated. SourcesMichael P. Farrell, Collaborative Circles: Friendship Dynamics and Creative Work, 2001.Christopher Alexander et al, A Pattern Language: Towns, Buildings, Construction, 1977.Mentioned (or that I wish I'd found a way to mention)Gamma et al, Design Patterns, 2004Eric Evans, Domain-Driven Design, 2003. I also like Joshua Kerievsky's pattern-language-like description of study groups, "Pools of Insight".Brian Marick, "Patterns failed. Why? Should we care?", 2017 (video and transcript)"Arches and Chains" (video) is a nice description of how arches work.Ryan Singer, "Designing with forces: How to apply Christopher Alexander in everyday work", 2010 (video)"Rational Unified Process" (wikipedia)James Bach, “Enough About Process, What We Need Are Heroes”, IEEE Software, March 1995.Firesign Theatre, "I think we're all bozos on this bus", 1971. (wikipedia)"Bloomers" (wikipedia article about a style of dress associated with first-wave feminists).CreditsThe picture is of Dawn and me sitting on our "Stair Seat", where we observe the activity on our lawn, sidewalk, and street. Which mainly consists of birds, squirrels, and people walking dogs. But it still fits Christopher Alexander's pattern of that name.

“Collaborative modeling is getting the relevant people into a room to solve a problem or get on the same page about what it is you're solving and getting some directions for that solution." Evelyn and Gien are the co-authors of “Collaborative Software Design: How to Facilitate Domain Modeling Decisions”. In this episode, we discussed collaborative software design and why we need it in software development. Evelyn and Gien started by explaining the Cynefin framework in software development and the importance of having heuristics for making quick decisions. We then dived deep into discussing what collaborative modeling is, how to get people involved to collaborate, and the important role of a facilitator. We also talked about the socio-technical aspects and skills required in collaborative modeling, in particular, understanding the influence of cognitive bias and ranking. Towards the end, we discussed when we should do a collaborative modeling exercise, how to structure it, and tips for doing it remotely.   Listen out for: Career Journey - [00:06:53] Collaborative Software Design - [00:09:28] Complicated vs Complex Problems - [00:12:24] Heuristics - [00:15:07] Collaborating Modeling - [00:19:03] The Facilitator Role - [00:24:55] Socio Technical Skills - [00:30:10] Cognitive Bias - [00:33:10] The Influence of Ranking - [00:38:51] Collaborative Modelling Structure - [00:47:00] When to do Collaborative Modeling - [00:51:38] Remote Collaborative Modeling - [00:55:34] 3 Tech Lead Wisdom - [00:58:45] _____ Evelyn van Kelle's BioEvelyn van Kelle is a strategic software delivery consultant, with experience in coaching, advising, facilitating, and guiding organizations and teams in designing and maintaining socio-technical systems. She blends different techniques, tools and approaches from behavioral and social sciences, collaborative modeling and Domain-Driven Design, to help leadership teams achieve sustainable transformations. Evelyn loves to share her knowledge by speaking at international conferences and meetups. Gien Verschatse's BioGien Verschatse is an experienced consultant and software engineer that specializes in domain modelling and software architecture. As a Domain-Driven Design practitioner, she always looks to bridge the gaps between experts, users, and engineers. As a side interest, she's researching the science of decision-making strategies, to help teams improve how they make technical and organizational decisions. She shares her knowledge by speaking and teaching at international conferences. When she is not doing all that, you'll find her on the sofa, reading a book and sipping coffee. Follow Evelyn: LinkedIn – linkedin.com/in/evelynvankell X – @EvelynvanKell Follow Gien: LinkedIn – linkedin.com/in/gien-verschatse X – @selketjah _____ Our Sponsors Miro is your team's visual workspace to connect, collaborate, and create innovations together, from anywhere.Sign up today at miro.com/podcast and get your first 3 Miro boards free forever. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/147 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

Matt Boyle is an Engineering Manager for Cloudflare based out of London. His team's goal is to create tools that increase the productivity and efficiency of other engineers. He is the author of “Domain-Driven Design with Golang” and speaks about his experience and motivation for writing the book. In this episode Matt takes us through his journey through the tech industry. 00:00 Introduction 03:30 What is Matt Doing Today?12:20 First Memory of a Computer17:20 Education in the United Kingdom23:30 First Programming Class  27:20 First Tech Jobs32:30 Moving to Platform Engineering42:30 Moving to a Startup45:40 Becoming a Full Stack Engineer51:20 Gaining Interest in Go58:50 Applying to Cloudflare  1:03:20 Taking Opportunities and AI1:13:00 Matt's Book1:22:45 Contact InfoConnect with Matt: Matt's Site:  https://mattjamesboyle.com/Mentioned in today's episode:Cloudflare: https://www.cloudflare.com/Matt's Book: https://www.amazon.com/Domain-Driven-Design-Golang-maintainable-business-ebook/dp/B0BNJ8KHYN/ref=sr_1_1?crid=NBJWXOCW6RGQ&keywords=domain+driven+design+golang&qid=1671189939&sprefix=domain+driven+design+golang%2Caps%2C294&sr=8-1%E2%80%A6Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses : https://ardanlabs.com/education/ Live Events : https://www.ardanlabs.com/live-training-events/ Blog : https://www.ardanlabs.com/blog Github : https://github.com/ardanlabs

Ashley Peacock, author of the book Creating Software with Modern Diagramming Techniques, speaks with SE Radio host Akshay Manchale about diagrams in software engineering. They discuss the power of diagramming and some reasons we don't fully use it as often as we should. Ashley contrasts historical use of UML diagrams versus modern diagrams, which don't have hard rules about representations. The episode examines different types of diagrams through an example application and how it could be built with modern tools such as Streamy to simplify the building, versioning, and maintenance of diagrams.

We chat with Oliver Drotbohm about what Domain-Driven Design is and how it might intersect with Microservices, Monoliths, or Moduliths. Mentioned resources: Parnas on modularity Chris Richardson – Introducing Assemblage - a microservice architecture definition process Spring Modulith Project Introducing Spring Modulith Discuss this episode: https://discord.gg/nPa76qF

Matthew Boyle, the author of Domain-Driven Design with Golang, sits down with Jon & Mat to talk about (you guessed it!) DDD with Go.

Matthew Boyle, the author of Domain-Driven Design with Golang, sits down with Jon & Mat to talk about (you guessed it!) DDD with Go.

In episode 68 of the We Hack Purple Podcast host Tanya Janca dives into Domain Driven Design (and development) with Gagandeep Singh. Gagandeep is an avid blogger, and Tanya read his article on DDD and just had to interview him. We discussed if Design Driven design or development are those the same thing (they aren't!), the security advantages of DDD, how Trusted Types and Content Security Policy Header come into play! We discussed the concept of having the security of a feature be part of the design and feature itself, and the huge security advantages we can expect to see. To hear more, you need to see the episode! Gagandeep's Bio:Gagandeep Juneja is an experienced Information Security professional working in the Information Technology and Services Industry. Working in Application Security domain, security assessment, threat modeling, architecture review, DevSecOps and guidelines for security technologies to develop effective secure solutions. In his opinion if we focus on securing code which will result in fewer vulnerabilities in the solution. Domain Driven Design sets the bar higher for software development, providing an efficient way to designing and developing a more secure IT solution. His blog: https://securityintelligence.com/posts/secure-coding-domain-driven-design/ Very special thanks to our sponsor: The Diana Initiative! A conference committed to helping all those underrepresented in Information Security - Monday August 7, 2023 In-Person at The Westin Las Vegas Hotel & Spa  Join We Hack Purple! We have new courses in the We Hack Purple Academy! Join us in the We Hack Purple Community:  A fun and safe place to learn and share your knowledge with other professionals in the field. Subscribe to our newsletter for even more free knowledge! You can find us, in audio format, on Podcast Addict, Apple Podcast, Overcast, Pod, Amazon Music, Spotify, and more!   

Tim Mitra comes on to talk about the some skills which are helpful for large teams, also how to gauge Apple's rumors and of course yak shaving.Guest Tim Mitra (website) Mastodon  @timmitra@mastodon.social GitHub @Timmitra Twitter @TimMitra More Than Just Code Podcast  Spockcast Podcast Pragmatic Hero's Journe‪y RoundaboutFM Related Links Learning Domain Driven Design ATP Episode 520 Stringslint Related Episodes E142 - Mobile System Design with Tjeerd in 't Veen E137 - Humane Development with Jill Scott E123 - Microapps Architecture with Majid Jabrayilov E76 - Scaling and Security with Jeroen Leenarts E87 - Core Data Fun with Tim Mitra We talked about  (00:00) - Help? (01:09) - Video Games (04:15) - Buzzwords and Trends (09:36) - QA and Testing (16:35) - Multi Disciplinary Engineering (17:54) - Programming Language for Getting Started (21:58) - Breaking Things Down (26:40) - Domain Driven Design (35:25) - Apple Rumors Social MediaTwitter Leo - @leogdionTwitter BrightDigit - @brightdigitLinkedIn - @leogdionGitHub - @brightdigitGitHub - @leogdionTikTok - @brightdigitMastodon - @leogdion@c.imYoutube - @brightdigitCreditsMusic from https://filmmusic.io"Blippy Trance" by Kevin MacLeod (https://incompetech.com)License: CC BY (http://creativecommons.org/licenses/by/4.0/) ★ Support this podcast on Patreon ★

Naoya Ito さんをゲストに迎えて、Rust, 関数型、プログラミングなどについて話しました。(2022/10/24 Rebuild Meetup イベントにて収録) スポンサー: GMOインターネットグループ株式会社 Show Notes Takuto Wada (@t_wada) / Twitter power-assert Hacker News exa: A modern replacement for ‘ls'. fd: A simple, fast and user-friendly alternative to 'find' TypeScript による GraphQL バックエンド開発 Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin Rebuild: 328: Therapeutic Podcasting (naan) Parcel Qwik Midlife crisis Don't Let Architecture Astronauts Scare You – Joel on Software Studio Display 徹底比較してみた！

Susanne Kaiser is a software consultant working with teams on microservice adoption. Recently, she's brought together Domain-Driven Design, Wardley Mapping, and Team Topologies into a conversation about helping teams adopt a fast flow of change. Today on the podcast, Wes Reisz speaks with Susanne about why she feels these three approaches to dealing with software complexity are so complementary. The two then work through some of the patterns she's seen in her consulting work and discuss how to get started, sequencing, and the effect of overall team size in applying these patterns. Read a transcript of this interview: https://bit.ly/3z1966T Subscribe to our newsletters: - The InfoQ weekly newsletter: https://bit.ly/24x3IVq - The Software Architects' Newsletter [monthly]: https://www.infoq.com/software-architects-newsletter/ Upcoming Events: QCon Plus online: https://plus.qconferences.com/ - Nov 30 - Dec 9, 2022 QCon London https://qconlondon.com/ - March 26-31, 2023 QCon San Francisco: https://qconsf.com/ - Oct 2-6, 2023 Follow InfoQ: - Twitter: https://twitter.com/InfoQ - LinkedIn: https://www.linkedin.com/company/infoq - Facebook: https://bit.ly/2jmlyG8 - Instagram: https://www.instagram.com/infoqdotcom/ - Youtube: https://www.youtube.com/infoq