10600 Westminster Blvd
Westminster, CO 80020
Founder and Owner at Virtual Genius
Look for him speaking at user groups, on the No Fluff Just Stuff conference tour in the United States, and at local and international conferences. Paul is from Perth, Australia, but chooses to live, work and play with his amazing wife and two children in Denver. He tweets with an Australian accent at @ThePaulRayner and blogs at thepaulrayner.com
Posted Tuesday, May 7, 2013I’m often asked about what teams doing Domain-Driven Design (DDD) should do in the way of documentation.The question What types of Written Design Documents are used in DDD projects?) came up on Stack Overflow and I started to write a response, butmore »
Posted Friday, February 15, 2013On Monday night at our DDD Denver meetup we ended up having a valuable and lively group discussion using a modified “Lean Coffee” format. The four questions we covered (in order) were: Where to start in developing a domain model? What is tmore »
Posted Thursday, February 14, 2013I had content in Word documents that I needed to convert to Asciidoc for our book. Here are the steps I found to work best: Save Word doc as HTML Encode as UTF-8 Use pandoc to convert from HTML to AsciiDoc Use Sublime Text 2 search and replace (using more »
Posted Thursday, February 7, 2013Saw directory listing coloring at Golden Ruby Users Group this week, and needed to have it! LsColors LS_COLORS='di=1:fi=0:ln=31:pi=5:so=5:bd=5:cd=5:or=31:mi=0:ex=35:*.rpm=90' export LS_COLORS ls, colors and Terminamore »
Posted Thursday, February 7, 2013I’ve found the Ruby Koans to be brilliant for exposing a learner to aspects of the language that are not obvious, or even weird, at first glance. Indexing Ruby Arrays For example, let’s look at a koan for accessing array elements: def tesmore »
Posted Wednesday, February 6, 2013In my effort to master Ruby this year, I started this morning working through Ruby Koans. I just completed these tests and was intrigued by the comment in the second koan: def test_some_system_objects_always_have_the_same_id assert_equal 0, false.objmore »
Posted Monday, February 4, 2013Why Octopress? Here are 4 good reasons from AlBlue’s blog to consider using Octopress for a technical blog: Jekyll-based Markdown content Stylish Plugins See also Octopress Is Pretty Great, which has a great description of not only the positmore »
Posted Friday, February 1, 2013This is a review of the book Implementing Domain-Driven Design by Vaughn Vernon, based on the Safari Books Online rough cut edition. The book is also currently available for preorder on Amazon.com, with a scheduled release date of February 14, 201more »
Posted Wednesday, January 2, 2013I noticed today on my MBP running Mountain Lion that using “Open With” (control+click on a file in Finder) showed duplicate entries for the file. I’m unsure as to what I did that caused this problem to happen, though a recent thread omore »
Presentationsmore » more » more » more » more »
Build your awareness of the basic concepts and value of Domain-Driven Design (DDD) in one day through group exercises, paired code walkthroughs, lecture and games.
Understand what DDD is and when and why it is valuable to software intensive organizations. Overview the basic principles and processes needed develop the useful sort of models, tie them into implementation and business analysis, and place them within a viable, realistic strategy.
- What is DDD and how is modeling useful?
- Developing a shared modeling language to enable effective collaboration
- Using reference scenarios to guide modeling
- What makes a model useful to a software project?
- Architectural options for implementing DDD
- Aggregate design - applying effective aggregate design for both relational and NoSQL solutions
- Domain events - decoupling, scaling and modeling chronology in distributed systems
- Prioritizing sophisticated design for where it will have the greatest impact
- Clarifying a shared vision
- Mapping the terrain of your systems to enable effective modeling and design
- Integrating agile with rigorous design
- Succeeding with DDD and avoiding common adoption pitfalls
This presentation seeks to provide a solid introduction to the fundamentals of DDD. Learn why modeling a complex business domain in software is so advantageous to your business and ways in which your team can go about delivering software models to give your business a competitive edge.
The philosophy of domain-driven design (DDD) – first described by Eric Evans in his book [of the same name – is about placing our attention at the heart of the application, focusing on the complexity that is intrinsic to the business domain itself. We also distinguish the core domain (unique to the business) from the supporting sub-domains (typically generic in nature, such as money or time), and place appropriately more of our design efforts on the core.
Domain-driven design consists of a set of patterns for building enterprise applications from the domain model out. In your software career you may well have encountered many of these ideas already, especially if you are a seasoned developer in an OO language. But applying them together will allow you to build systems that genuinely meet the needs of the business.
The premise of domain-driven design is two-fold:
- For most software projects, the primary focus should be on the domain and domain logic; and
- Complex domain designs should be based on a model.
Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.
Note: Laptops are not required - there is no hands-on coding for this workshop.
Not every part of a software system will be well-designed. How do you know where to put the time and effort to refine the design, or refactor existing code? Learn how strategic Domain-Driven Design (DDD) patterns can show you how to know which parts of your system matter most to your business and how to focus your team's design efforts most effectively.
Context mapping and Core Domain are key concepts in DDD, providing valuable techniques and insights into where to focus your design attention, yet most developers have never heard of them. This session will introduce the tools of strategic DDD and show you how they can shine a light on your design challenges.
Come on a guided tour of how applying Domain-Driven Design (DDD) building block patterns can make your code cleaner, more expressive, and more amenable to change. We cover examples of DDD patterns such as entities, value objects, closure of operations and side-effect-free functions. We will focus particularly on how implementing value objects can lead to more supple design.
When good design really matters, DDD building block patterns enable your design to model the business domain you are working with more richly. They allow you to collaborate with domain experts to build deep, useful models of the domain in your code that solve difficult business problems with elegance and simplicity.
This is a highly interactive modeling session which walks through diagrams and code samples to demonstrate how the application of these patterns to modeling can make writing and reading coding fun again, while improving the effectiveness of the code you write. Come prepared to think, ask and answer questions, and learn how to write the best code where it matters most.
Many of the problems encountered in scaling, parallelizing and distributing systems that tend to be addressed in ad-hoc ways are actually deeply connected with the manner in which the business domain has been modeled. Domain-Driven Design (DDD) has rich modeling resources for tackling concurrency, transactional and distribution boundary issues within the domain model itself, enabling teams to be more effective in dealing with business complexity and change.
Learn about how aggregates can enrich your domain models, improve system performance and loosely couple your systems. We will give examples of how aggregate design choices are manifested in NoSQL data schemas, focusing particularly on MongoDB, and the consequences of making these choices for domain modeling, performance, and scaling.