Brownfield Development Strategies

008c45c68ff49184796deda5faca4126?s=47 Craig Berntson
August 09, 2018
26

Brownfield Development Strategies

We're probably familiar with the book "Working Effectively with Legacy Code" by my friend Michael Feathers. This is a great book that explains how to keep legacy code running. But how do we handle re-architecting legacy applications? This presentation gives some valuable techniques to enable your rearchitecting efforts.

008c45c68ff49184796deda5faca4126?s=128

Craig Berntson

August 09, 2018
Tweet

Transcript

  1. BROWNFIELD DEVELOPMENT STRATEGIES Craig Berntson HealthEquity

  2. Author - Continuous Integration in .NET - .NET Curry Technical

    Speaker - North America - Europe .NET Architect / Engineer - HealthEquity
  3. TODAY’S AGENDA ❑ Define Brownfield ❑ Issues and challenges ❑

    Traditional development ❑ Layering ❑ Modern approaches
  4. BROWNFIELD vs GREENFIELD vs LEGACY Concern Greenfield Brownfield Legacy Project

    state Early development, new features New features and/or production maintenance Primarily maintenance. No new features Code maturity All code actively worked on Some new code; All code maintained for defects Little code developed except for defects Architectural review Reviewed and modified at all levels and times Only when significant changes requested Rarely if ever Practices and processes Developed as work progresses Mostly in place, but may not be working for the team/project Focused on critical defects Project team Newly formed Mix of old and new with fresh ideas and historical biases Very small, maintains status quo Unit Tests Close to 100% coverage May have some None
  5. WHAT IS BROWNFIELD? Existing codebase Potential for improvement Contamination Brownfield

    Application Development in .NET
  6. ISSUES YOU MAY ENCOUNTER ❑ Pain points ❑ Friction ❑

    Challenge assumptions ❑ Client’s expectations ❑ Boss’s expectations ❑ Rewrite decisions
  7. CHALLENGES ❑ Technical factors ❑ Political factors ❑ Team morale

    ❑ Client morale ❑ Management morale ❑ Agent for change
  8. ECOSYSTEM ❑ Version control ❑ Continuous integration ❑ Automated testing

    ❑ Software metrics and code analysis ❑ Defect management
  9. METHODOLOGY INDIVIDUALS AND INTERACTIONS WORKING SOFTWARE CUSTOMER COLLABORATION RESPONDING TO

    CHANGE
  10. AGILE PRINCIPLES ❑ Satisfy the customer ❑ Welcome change requirements

    ❑ Deliver working software frequently ❑ Business people and developers work together ❑ Build projects around motivated people ❑ Face-to-face conversation ❑ Working software is primary measure of success ❑ Sustainable development ❑ Technical excellence ❑ Simplicity ❑ Self-organizing teams ❑ Reflect then tune and adjust
  11. DEVELOPMENT TEAM ❑ Agile ❑ Cross-functional ❑ Keep it small

    ❑ Open-minded ❑ Passion to learn ❑ Empowered ❑ Failure is acceptable ❑ Work/Life balance ❑ Dedicated
  12. DOS Windows Web Mobile Cloud

  13. None
  14. None
  15. TIERS - PHYSICAL Presentation Tier Business Logic Tier Data Access

    Tier Database
  16. LAYERS - LOGICAL Views Controllers Service Layer Domain Model Repository

    Layer Etc. Presentation Tier Business Logic Tier
  17. ANTICORRUPTION LAYER ❑ Well defined contract ❑ Changes in one

    layer don’t affect calling code ❑ Expose only minimum required interface ❑ Decouples layers ❑ “Seams”
  18. SEAMS User Interface Layer Service Layer Domain Model Repository Layer

    Seam Seam Seam
  19. VERTICAL LAYERS Presentation Layer Presentation Validation Layer De/Serialization Layer Application

    Service Layer Logging Layer Data Access Translation Layer Data Interface Layer Data Access Layer Performance Monitoring Layer User Validation and Authorization Layer Exception & Error Handling Layer
  20. Presentation Tier Domain Logic Tier Data Access Tier VERTICAL FUNCTIONALITY

    Customer Management Order Entry Inventory Management Invoicing
  21. TRADITIONAL APPROACH – DATABASE CENTRIC User Interface Database

  22. MODERN APPROACH – USER CENTRIC Database Domain User Experience User

  23. Person’s perceptions and responses resulting from the use and or

    anticipated use of a product, system, or service - International Organization for Standardization (ISO)
  24. UX HONEYCOMB Valuable Useful Desirable Accessible Credible Findable Usable http://semanticstudios.com/user_experience_desig

  25. UX IS MORE THAN UI How screen is laid out

    Flow from textbox to textbox Flow from screen to screen Is data logically grouped Keyboard vs mouse navigation Verbiage, fonts, colors Whitespace Accessibility Sound
  26. None
  27. You should focus on the domain, rather that the database,

    the servers, and the programming language. - “Brownfield Application Development in .NET”
  28. In a data-driven approach, the attributes of an object are

    discovered first and then responsibilities are meted out as a function of which object holds which data. A behavioral approach mandates the assignment of responsibilities first. Only when you are satisfied with the distribution of responsibilities among your objects are you ready to make a decision about what they need to know to fulfill those responsibilities and which parts of that knowledge they need to keep as part of their structure. - “Object Thinking”
  29. Responsibilities are not functions, although there is a superficial resemblance.

    Perhaps the easiest way to differentiate between a responsibility and a function is to remember that the former reflects expectations in the domain – the problem space – while the latter reflects an implementation detail in the solution space – the computer program. - “Object Thinking”
  30. User Interface Database Database Domain User Experience User TRADITIONAL vs

    MODERN
  31. DOMAIN DRIVEN User Interface Layer Service Layer Domain Layer Repository

    Layer Seam Seam Seam
  32. SUB-DOMAINS Product Database Order Entry Inventory Management • Sale price

    • Item ID • Manufacturer • Description • Order Quantity • Item ID • Manufacturer / Reseller • In-stock Quantity • Reorder Quantity • Lead time
  33. None
  34. MICROSERVICES Order Entry Address Verification Shipping Calculator

  35. MICROSERVICES ADVANTAGES ❑ Small, defined functionality ❑ Web API &

    JSON ❑ Less chance of introducing bugs ❑ Called asynchronously ❑ Easy to deploy ❑ Accessible to entire enterprise / application
  36. SERVERLESS ❑ You don’t allocate server ❑ Small units of

    code ❑ Cloud infrastructure handles scaling automatically ❑ Azure Functions / AWS Lambdas ❑ Best used for glue code vs. business code
  37. Web UI External Interfaces DB Controllers Use Cases Entities Enterprise

    Business Rules Application Business Rules Interface Adapters Frameworks & Drivers
  38. REVIEW ❑ Define Brownfield ❑ Issues and challenges ❑ Traditional

    development ❑ Layering ❑ Modern approaches
  39. CONTACT / QUESTIONS cberntson@healthequity.com @craigber www.dotnetcurry.com www.speakerdeck.com/craigber

  40. None