Zmiana paradygmatu programowania z AI [DevTalk TRIO S04E06]

Technological Concepts & Main Claims

• Changing programming paradigms (OO / functional / procedural) is mostly about “style,” not correctness—provided DDD boundaries are good.

  • The panel argues that with good context model boundaries, switching paradigms becomes a mechanical refactoring task.
  • With bad boundaries, the project “moves backwards” regardless of paradigm—so the priority is domain boundaries / DDD, not debate over code style.

• AI leverage: the paradigm shift is refactoring, but AI can shorten the process.

  • They claim converting an aggregate between styles typically takes under ~1 hour (depending on skill).
  • AI helps by automating or assisting parts of the migration.
  • The goal is not that AI “replaces programmers,” but that it reduces effort using a known checklist-like procedure.

---

Product Features / Tutorial-Like Procedure (The Demonstrated Workflow)

Ignacy describes a repeatable refactoring workflow to change paradigm while preserving behavior:

1. Start with an aggregate in an object-oriented style

   • Example domain: Smart Schedule system from a “Domain drivers” course.
   • The aggregate has “rich” methods (behavior-rich OO design).

2. Preserve observable behavior first

   • Refactoring should ensure no changes to externally observable behavior.
   • Safety net is test-driven, not structure-driven.

3. Create a higher-level unified test layer

   • “Lift” tests from the aggregate level toward the application/module façade level.
   • Introduce a facade/module entry point and run behaviors through it.

4. Introduce a Domain-Specific Language (DSL) for behaviors

   • Create a DSL that expresses allowed domain operations (e.g., create a project, allocate resource, release resource).
   • The DSL layer should be detached from implementation details of the aggregate (independent of whether the underlying aggregate uses methods, functions, etc.).
   • AI role (as described): the DSL can be produced by analyzing existing tests and proposing the set of domain operations.

5. Implement the DSL using different “driver” implementations

   • A driver maps DSL operations to actual domain behavior.
   • Phases shown:
     • First driver delegates to the OO aggregate methods.
     • Later driver changes how domain logic executes.

6. Convert the OO aggregate to a functional-style representation

   • Remove “methods” and instead use pure-ish functions that take current state + command and optionally return an updated data structure.
   • Although not “pure functions” in a strict academic sense, it’s treated as a clean functional style.

7. Verify: tests/scenarios remain unchanged

   • Once the DSL + driver pattern are in place, the DSL test scripts do not change when the underlying aggregate implementation changes.
   • You effectively swap DSL driver implementations, not the test suite.

---

Reviews / Audits / Guidance Points

• Audits and business validation:

  • They claim the approach makes it easier to show tests to domain experts/business stakeholders and get confirmation that tests cover intended behavior.

• Human readability of DSL:

  • The DSL is described as “normal to humans,” addressing the common concern that tests become too technical.

---

Constraints / Limitations (When Not to Use This Approach)

They warn about large “blast radius” costs if the system is not well modularized:

• If behavior selection spans many modules (e.g., mixing database, REST, JDBC, and other concerns widely), implementing a unified DSL across modules becomes too expensive.

Therefore, the recommended rule is:

• Only run this skill when DDD/context boundaries are already good.
• Otherwise, fix boundaries first; do style migration later.

---

Key Takeaway

• Paradigm debates are largely unnecessary when DDD boundaries are correct.
• Paradigm migration becomes a mechanical checklist/refactoring process—enabled and accelerated by AI-assisted DSL/test lifting and driver swapping.

---

Main Speakers / Sources

• Ignacy: Demoing the “skill” and explaining the DSL/test/driver workflow.
• Sławek: Discussing boundaries/DDD and responding to concerns about the workflow.
• Host / other panelists from DevTalk TRIO: Intro and discussion about paradigm eras and style debates.