Domain Driven Design: The Good Parts

Presenter Jimmy Bogard

  • Part 1
    • The Majestic Monolith
      • A super large system that does everything
      • Their first Domain Driven Project
        • Texas Juvenile Justice Department
        • The state building a system for each county to use
        • First agile project for Texas government agency
        • Contract was per sprint
          • In hindsight decided a bad idea
        • First DDD project for any Texas government agency
    • Project Goals
      • Increase Knowledge Sharing of data in county relevant to a particular case
      • Comprehensive system covering all aspects of juvenile process
      • Complete picture of Juvenile so can make good decisions about how to handle case
      • Very idealistic
      • Legal process in the state of Texas very complicated and part of system.
    • Since agile started making User Stories and Personas
      • Had 72 personas, that is a lot
        • Color coded by Agency
        • In hindsight, so many personas indicated perhaps should not be one big system
        • Different bounded contexts, perhaps by agency?
        • Lesson 1: Bonded Contexts are a real thing
      • Person table
        • Ambiguous Modeling problem.  One size fits all table
        • Lesson 2: Ambiguous modeling means should split system
      • Competing Priorities
        • Different agencies felt different things should be priority
        • Lesson 3: Core Domain needs consensus
      • Everyone agreed on the word ‘offense’
        • Although it had a different context and meaning for each agency
        • Lesson 4: ubiquitous language needs consensus
      • Huge interfaces and classes
        • Lesson:5 structural components are least important thing to focus on
      • Huge application, did ship and still being worked on, but one massive MVC system
        • Many compromises
        • Ended up being a big ball of mud, but it works.  Learned many lessons
  • Part 2:  The Do-over
    • Same client, but the adult justice system
    • Client didn’t want to build one big system again
      • Too costly and risky
      • Build app for one agency at a time
    • Applied lessons from first system that went somewhat wrong
      • Lesson 1: Cohesiveness brings clarity and deeper insight
        • Built around bounded contexts
          • System just for Prosecution piece
          • Built around the ‘case’ as that is most important thing to prosecution
      • Lesson 2: Flexible in places, rigid in others
        • They had a user/role/permissions mapping instead of hard coding roles to permissions
      • Lesson 3: Sometimes the model is a step up from their model
        • Built simple work flow
        • Work flow driven by queues
          • This replaced searching by case number, person and comments
      • Lesson 4:  Don’t blindly follow patterns
        • Code Changes
          • Collapse Layers
          • Had system model what it actually did
            • Get data to show
            • Update data
            • Controllers got thin, since just did gets and posts
              • Mediators took work from controllers
              • Mediators replaced repository
        • Organized project by Feature instead of by kind
          • Kept all pieces of feature together

 

Leave a Reply

Your email address will not be published. Required fields are marked *