Pragmatic Refactoring with Domain-Driven Design

Code: Craft-refactor
Category: Patterns & Craftsmanship
Format: 50% lecture / 50% workshop
Duration: 3 days
Target audience: developers
Enrollment: Groups, companies
Venue: Client's office.

Refactorings like “Extract Method”, “Replace If with Guardian” or “Extract Object” improve the readability, but don’t rescue projects, where the model is fundamentally broken.

How to perform a refactor which looks like replacing an airplane’s engine? Of course, while flying. This workshop shows a handful of categorized typical problems gathered thanks to years of dealing with software on production, doing architectural audits and consulting in plenty of domains.

This is not yet another workshop where we go through a catalogue of typical code smells and ways of getting rid of those. During the coding exercises, we will analyze architectural problems which cannot be solved using standard refactoring techniques. We will take into account the fact that our software cannot afford a 3-month-long “rewriting” pause. Attendees will see a map that helps them navigate and solve architecture problems. Each problems is solved pragmatically, backed up with good engineering practices, Domain-Driven Design and rollback possibility.

We cover ways of communicating the technical debts to the business, soft skills that help us communicate the need of refactoring to people who we need to convince. We will talk about how to collect important business metrics which build a common understanding between IT and business stakeholders.

After the workshop, you will be ready to identify and repair architectural flaws and code problems using Domain-Driven Design, analyzing the history of your project, analyzing the business metrics, code stability, Test-Driven Development, object-oriented and functional programming, modularization and many more.

This workshop can last from 3 up to 5 days. The 4th and the 5th day can be dedicated to a fresh product, where we start from scratch, model and implement a green-field project, using the knowledge gathered within the first 3 days in the legacy context.

Alternatively, this can be applied as a series of consulting meetings, using your codebase.

Training Program

The content of our program can be customised during pre-training analysis.

  1. Common problems
    1. What to do with a big and “unsightly” class?
    2. What to do with a big but “aesthetic” class?
    3. How to repair the data inconsistency problem?
    4. My module/class has so many dependencies and so much business logic - how do I repair that?
    5. The model of my module does not fit the reality - how to safely fix that?
    6. I have so many inefficient reads from my database, the code looks ugly - what do I do?
    7. There are no clear boundaries in my codebase, how to introduce some?
  2. Proven Refactoring Path
    1. Finding and describing the problem
      1. Architectural drivers
    2. Marketing of your ideas
      1. Technical interlocutor
        1. Egoless programming
      2. Business/non-technical interlocutor
        1. The vector of new business possibilities
        2. The vector of new business possibilities for all new clients
        3. The vector of new business possibilities for one strategic client
        4. Safe rollback - we are not going to break anything
    3. Recognizing the location of the problem
      1. Metrics gathering and interpretation
      2. Finding the critical points
      3. “Smells” identification
      4. Stable vs unstable code
      5. Your code as the crime scene - your repository and history
      6. Domain-Driven Design
    4. Planning of the changes
      1. “The ugly duckling” effect
      2. “You are never done” problem
    5. Introduction of the changes
      1. Tactical/mechanical refactorings
      2. Strategic/architectural refactorings
    6. Deployment of the changes
      1. Cycles and micro-cycles
    7. Observation of the effects
      1. Safe rollback
  3. Continuous refactoring
    1. IDE support
    2. Identification of the “seams”
      1. Common understanding and education
        1. Code Review
        2. ArchUnit and other useful tools
    3. Conventions as one class of architectural drivers
    4. Refactoring without knowing the domain
      1. How to do that safely?
  4. Refactoring for the sake of a new function
    1. A brand new business function - integration
    2. Current business function’s flaws
    3. Improvement of the quality attributes
    4. Building trust
    5. Business metrics as the key factor of the process of convincing
  5. Deployment
    1. Tests
      1. Finding “seams”
      2. Lowering the seams
      3. Characterization tests
      4. Tests and seams as a technique of finding modules boundaries and new business possibilities
    2. Big Bang Release Problem
    3. Step by Step Techniques
    4. Parallel Models as the only sane way of safe strategic refactoring
      1. Safe rollback
      2. Logs
      3. Advanced metrics
      4. Safe-healing system
      5. Building trust with business from day 1
  6. Use of Domain-Driven Design
    1. Encapsulating the “WHAT” into application services
    2. Encapsulating the “HOW AND WHY” into Domain-Driven Design building blocks
    3. Ubiquitous Language
    4. Value Objects is easier to deal with than Entity
    5. Value Objects, Aggregates and Policies discovering
    6. Policy - encapsulating the flexibility in a stable interface
    7. Refactoring of a large-scale system into 3 layers
      1. Operations
      2. Policies
      3. Decision Support
    8. Thinking in functions
    9. Complexity encapsulation done in one place


Download PDF

Trainers

Meet the experts who will conduct your training.

Michał Michaluk

Jakub Pilimon

Contact us for a free consultation.

Firstname and lastname:
Company:
E-mail:
Phone:
Subject:
Message:

If you prefer direct contact then you can always call.

Iwona Sobótka

Training coordinator


I agree to the processing of my personal data in accordance with the Law on the Protection of Personal Data in connection with sending a request via the contact form.

Providing the data is voluntary but necessary to process the query. I have been informed that I have the right to access my data, the possibility of correcting them, demanding stopping their processing.

The administrator of personal data is Bottega IT Minds, ul. Jana Sawy 2, 20-632 Lublin, Poland.

The information clausule