Presentation - Brainstorming your way from a Monolith to a Clean Architecture

Presentation - Intermediate - Brainstorming your way from a Monolith to a Clean Architecture

Speaker: Victor Rentea (http://www.victorrentea.ro)

Did you ever wanted to (re)write your enterprise application from scratch? I’m sure you did ! And I’m pretty sure the rewritten codebase would be two times smaller than it is now. But, given the time and budget for a rewrite, what would you do to keep it from becoming “legacy” again in 2 years?

Ok, Wake Up! Your boss won’t approve a rewrite! But still, what should you aim for with your asiduous refactorings and clean-ups?

Let me share with you what I believe to be the ideal mindset about an enterprise application: Pragmatic, Clean Evolutionary Architecture.

Pragmatic = Keep It Short & Simple

Clean = The Onion Architecture (Dependency Inversion Principle)

Evolutionary = Continuously redesign

Architecture = that will ensure Developer Comfort & Safety.

Tests, tests, tests = Responsible Development

It’s all basically a summary of the design principles that we distilled over the past 2 years developing 7 enterprise applications for our client (one of the largest of IBM Romania).

Agenda:

1. Introduction: KISS, DDD vs Transaction Script

2. Modeling Data

The Fit Entity that obeys you

Value Objects

Data Transfer Objects that isolate your Entities

3. Extracting Logic

Mappers that encapsulate conversion

Facades that implement logic

Extracting Domain Services for KISS or DRY

Logic Extraction Patterns

4. The Clean Architecture

Dependency Inversion Principle -- the best of OOP (cf. Uncle Bob)

Consuming Repositories

Calling External Services

5. Testing

Principles - Design Feedback

Testability

A new style of TDD: Extract and Split

My goal with this talk is basically to open the eyes of enterprise application developers to think critical of the (often) imposed enterprise architecture they follow, and to empower them to think out-of-the-box. Hopefully, they will then be able to tackle unexpected functional complexity with an appropriate minimalistic design that would maintain a low design complexity (=less code =happier developers). It's a story that I've gone through with teams on numerous projects, although I didn't had the chance to talk about it in any public event until now.

To keep things simple, the discussion will conceptually start from a simplistic one-class system and grow the architecture with additional patterns, justifying at all times the added complexity with fundamental principles of good design + a lot of discussions. Basically, I would love to hear you continuously arguing with me why I’ve added the complexity as I present it to you. This way, adding constructs as we go, we’ll end up very close to the architectures that we actually use today for our apps at my work.

Even though the talk is more on a conceptual level, you’ll see some code examples that support my decisions.

Target audience: Enterprise application developers (JavaEE, Spring, even non-Java) with at least 3 years of hands-on backend experience.

The talk will only address the backend architecture (from the controller to the database).

References: Clean Code (Robert C. Martin), Rethinking Java EE Patterns (Adam Bien), TDD by example (Kent Beck), Extreme Programming Explained (Kent Beck)