DEV Community: hello-ediflow

Building EDIFlow in TypeScript: Part 2 - Domain Layer Deep-Dive

hello-ediflow — Tue, 10 Feb 2026 11:08:44 +0000

Series: Building EDIFlow - A Clean Architecture Journey in TypeScript (Part 2/6)

Author: EDIFlow

Published: February 2026

Reading Time: ~10-12 minutes

Welcome Back! 👋

In Part 1, I shared why I built EDIFlow and why Clean Architecture was the right choice.

Now it’s time for the hard part: design decisions.

Today we focus on the Domain Layer — not the implementation details, but the decisions that shaped it.

What you’ll learn:

What objects to model (and what NOT to model)
Decision criteria for Entity vs Value Object
Trade-offs that influenced the design
Why DDD + Clean Architecture belong together
What you can reuse in your own systems

No perfect solutions — just real decisions with real trade-offs.

1. The First Question: What IS the Domain? 🤔

This sounds obvious, but it’s the hardest question in Clean Architecture:

“What belongs in the Domain Layer?”

Uncle Bob says in Clean Architecture:

“The Domain Layer contains Enterprise Business Rules. These are the rules that would exist even if the application didn't exist.”

Translation: Domain = pure business logic, independent of technology.

My Challenge with EDIFlow

EDIFlow parses messages. But what’s the “domain”?

First instinct (wrong):

Domain = Parsing logic

❌ Parsing is technical, not business.

I spent a week building parsers in the domain layer. Big mistake! When I tried to add X12 support, I had to change the domain. That's when I realized: if adding a new format changes your domain, your domain is wrong.

Second try:

Domain = Message structure (segments, elements)

⚠️ Better, but still technical.

Final answer:

Domain = Business concepts that exist independently
- A message has a type
- A message has a version
- A message has validation rules
- A message has identity

✅ This is the domain. It exists before parsing, after parsing, and independent of any parser.

Key lesson: Don't confuse technical implementation with business concepts. I learned this the hard way!

2. Enter Domain-Driven Design 📚

Now I knew what belongs in the Domain Layer. But I still had a problem: Which objects do I create?

Clean Architecture tells me where logic belongs. It doesn’t tell me how to model that logic.

That’s where Domain-Driven Design (DDD) helps. Eric Evans describes several building blocks for domain modeling:

Entities - Objects with identity
Value Objects - Objects defined by value
Aggregates - Cluster of entities with a root
Domain Services - Operations that don’t belong to objects
Repositories - Persistence abstractions
Factories - Complex object creation

Note: These ideas existed before DDD, but Evans made them clear and practical for domain modeling.

3. Why DDD + Clean Architecture? 🔗

Why do I need both? Because they solve different problems:

	Domain-Driven Design	Clean Architecture
Answers	WHAT to model	HOW to structure
Question	What objects? What relationships?	Where does code go?
Gives you	Entities, Value Objects, Aggregates	Layers, Dependencies, Boundaries
Goal	Model business correctly	Structure code maintainably

Together they’re powerful:

DDD tells you WHAT:
- EDIMessage is an Entity (identity)
- Version is a Value Object (value-based)
- Standard is an Enum (type-safe set)

Clean Architecture tells you WHERE:
- Entities live in Domain Layer
- Parsers live in Infrastructure Layer
- Use Cases live in Application Layer

Real example (compact):

DDD Decision:
"Version is a Value Object" (immutable, no identity)

Clean Architecture Decision:
"Version lives in domain/value-objects/ with zero dependencies"

Result:
✅ Correct model (DDD)
✅ Correct structure (Clean Architecture)
✅ Portable + testable

Both complement each other: DDD without structure = mess. Structure without domain insight = technical code without business value.

4. Why Focus Only on Entities & Value Objects? 🎯

DDD has many building blocks, but this article focuses on just two:

Entities - objects with identity
Value Objects - objects defined by value

Why only these two?

Honest answer: Because EDIFlow’s Domain Layer is simple:

✅ No Aggregates (EDIMessage is simple enough)
✅ No Domain Services (operations fit in objects or use cases)
✅ No Repositories in Domain (they belong in Infrastructure)
✅ No Factories needed (constructors are enough)

YAGNI applies here. Don’t add patterns you don’t need.

Later parts in the series:

Part 3: Use Cases, Services, DTOs
Part 4: Repositories, Parsers

5. The Big Decision: Entity or Value Object? 📦

I use a simple decision matrix:

Question	If YES →	If NO →
Does it have an ID?	Entity	Value Object
Can two be equal with different values?	Entity	Value Object
Does it change over time?	Entity	Value Object
Do I need to track its history?	Entity	Value Object

Applied to all EDIFlow domain objects:

Object	Has ID?	Equal w/ diff values?	Changes?	Track history?	Verdict
EDIMessage	✅	✅	❌	✅	Entity
Version	❌	❌	❌	❌	Value Object
MessageType	❌	❌	❌	❌	Value Object
Delimiters	❌	❌	❌	❌	Value Object
Standard	❌	❌	❌	❌	Value Object (Enum)
EDISegment	❌	❌	❌	❌	Value Object
EDIElement	❌	❌	❌	❌	Value Object

Pattern: Only EDIMessage has identity. Everything else is a Value Object.

Key insight (1:6 ratio):

1 Entity (EDIMessage)
6 Value Objects (everything else)

DDD takeaway: Start by assuming Value Object. Only choose Entity if identity truly matters.

See It In Action

Here's how the decision matrix plays out in real code:

// Entity: Has identity, can be equal despite different values
const message1 = new EDIMessage('ORDER-001', version, type, segments);
const message2 = new EDIMessage('ORDER-001', version, type, segments);
message1.equals(message2); // ✅ true (same ID!)

// Value Object: No identity, equals by value only
const v1 = new Version(Standard.EDIFACT, 'D.96A');
const v2 = new Version(Standard.EDIFACT, 'D.96A');
v1.equals(v2); // ✅ true (same value!)

const v3 = new Version(Standard.EDIFACT, 'D.01B');
v1.equals(v3); // ❌ false (different value!)

Why this matters: Two orders with same content are different orders (Entity). Two versions "D.96A" are the same version (Value Object).

6. The Hardest Decision: Polymorphism vs Simplicity 🎭

EDIFlow supports multiple formats (EDIFACT, X12, IDOC). Each has different rules.

How do I model this?

I struggled with this for days. Every approach felt wrong:

Separate classes = duplication
if/else = messy
Polymorphism = complex?

Let me show you the three options I considered:

Option 1: Separate Classes (Naive)

class EdifactVersion {}
class X12Version {}
class IdocVersion {}

Pros: Simple, clear

Cons: Duplication, hard to extend

❌ Rejected (violates DRY)

Option 2: if/else Everywhere

if (standard === 'EDIFACT') { ... }

Pros: One class

Cons: Breaks OCP, hard to test

❌ Rejected

Option 3: Polymorphic Value Object (Chosen)

class Version {
  private static PATTERNS = { EDIFACT: /.../, X12: /.../ };
}

Pros: One class, extensible, type-safe

Cons: Slightly more complex

✅ Chosen (best trade-off)

7. Trade-Off Example: Validation Strategy 📊

Approach	Pros	Cons	Chosen?
External Validator	Flexible	Separate logic	❌
Self-validating constructor	Fail-fast	Exceptions	✅
Factory method	Controlled	Extra layer	⚠️

Why self-validation: It makes invalid state impossible.

8. What I'd Do Differently 🤔

Let me be honest about mistakes and second thoughts:

Mistake #1: Almost Over-Engineered Version

What I almost did:

interface IVersion { ... }
class EdifactVersion implements IVersion { }
class X12Version implements IVersion { }

Why I didn't: YAGNI! The polymorphic approach works great. Don't create interfaces until you need them.

Lesson: Resist the urge to make everything "extensible." Simple solutions often stay simple.

Mistake #2: First Draft Had 50+ Classes

My very first attempt had separate classes for everything:

EdifactDelimiters, X12Delimiters
EdifactSegment, X12Segment
EdifactElement, X12Element

Why that was bad: Massive duplication. 80% of the code was identical.

What I learned: Look for patterns before creating classes. Most Value Objects are format-agnostic.

Thought #1: Should I Use Result Types?

Right now, constructors throw exceptions:

new Version(Standard.EDIFACT, 'INVALID'); // throws!

Alternative: Result types (functional style):

Version.create('INVALID'); // returns Result<Version, Error>

Why I didn't: Most TypeScript developers expect exceptions. Result types are great, but add learning curve.

Would I change it? Maybe in v2.0 with a Version.tryCreate() method. For now, exceptions work fine.

9. What You Get From This Design 🎁

✅ Type safety (less guessing)
✅ Invalid state impossible
✅ Clear separation of concerns
✅ Easier testing (pure logic)
✅ No breaking changes when adding formats

10. What's Next? 🚀

Part 3: Application Layer

Use Cases
Services
DTOs
Dependency Injection (no framework)

11. Conclusion 🎯

Domain design is about decisions:

What to model
How to classify objects
What trade-offs to accept

EDIFlow’s Domain Model:

1 Entity: EDIMessage
6 Value Objects: Standard, Version, MessageType, Delimiters, EDISegment, EDIElement

Rule of thumb: Start with Value Object. Promote to Entity only when identity truly matters.

📚 Series Navigation

Part 1 (Published):

Part 1: Why Clean Architecture?

Upcoming Parts:

Part 3: Application Layer - Use Cases & Services
Part 4: Infrastructure Layer & Monorepo
Part 5: Presentation Layer - CLI
Part 6: Lessons Learned & The Big Refactoring

💬 Let’s Discuss

How do you decide between Entity and Value Object in your projects?

Do you prefer decision matrices like this?
What trade-offs do you value most (simplicity, extensibility, strictness)?
Have you used DDD + Clean Architecture together?

I’d love to hear your approach — drop your thoughts in the comments.

🔗 Links & Resources

EDIFlow:

Community:

💬 Discord: EDIFlow Community
📣 GitHub Discussions

Books:

📚 Clean Architecture by Robert C. Martin
📚 Domain-Driven Design by Eric Evans
📚 Clean Code by Robert C. Martin

Part 3 is next: Application Layer.

Building EDIFlow in TypeScript: Part 1 - Why Clean Architecture?

hello-ediflow — Tue, 03 Feb 2026 06:14:36 +0000

Series: Building EDIFlow - A Clean Architecture Journey in TypeScript (Part 1/6)

Author: EDIFlow

Published: February 2026

Reading Time: ~7 minutes

1. Introduction - The Problem 🤔

I've been working in data integration for over 20 years. SOAP, REST APIs, and yes—EDI. Lots of EDI.

If you've ever worked with EDIFACT, you know the pain:

UNH+1+ORDERS:D:96A:UN'
BGM+220+ORDER12345+9'
DTM+137:20240201:102'
NAD+BY+BUYER123::92'

What does BGM+220 mean? What is DTM+137? What's ::92?

This is the "old school EDI" world:

❌ No human-readable names
❌ Just codes and tags (BGM, NAD, DTM...)
❌ Makes onboarding new developers incredibly hard

And the existing parsers? They don't help much:

// ❌ Typical EDI Parser - Generic segments
const bgm = message.segments.find(s => s.tag === 'BGM');
const docNumber = bgm?.elements[1]?.value;  // What is element[1]? 🤷

No type safety. No IntelliSense. No business logic.

After 20+ years of this, I had enough. I wanted to build an EDI library that:

✅ Maps to type-safe TypeScript business objects
✅ Uses Clean Architecture principles
✅ Makes EDI development enjoyable (yes, really!)

So I started EDIFlow.

But here's the honest truth: I didn't just want to build a library. I wanted to LEARN Clean Architecture by doing.

2. Why Clean Architecture? 📚

The Honest Answer: I Wanted to Learn It!

I first encountered Clean Architecture around 2020. Read the books:

I was hooked. The principles made so much sense:

Single Responsibility
Dependency Inversion
Separation of Concerns
Testability

But then I tried to apply it at work...

The Reality: Resistance to Change

Typical problems I faced:

🏢 "We've always done it this way"
😰 "New architecture? Too risky!"
⏰ "We don't have time to refactor"
🤷 "Why change if it works?"

The structures were too entrenched. No trust in "new" architectures. The typical corporate fears.

Sound familiar?

The Solution: Build My Own Project

I realized: The best way to learn Clean Architecture is to build something real from scratch.

Not a TODO app. Not a toy example. A real-world library that solves a real problem.

So when I decided to build EDIFlow, I made a commitment:

✅ Clean Architecture from Day 1
✅ TDD (Test-Driven Development)
✅ Agile principles (even solo!)
✅ No compromises on code quality

Could I have hacked it together in a weekend? Sure!

But where's the learning in that? 🤷

So... Was Clean Architecture Worth It?

This is the question everyone asks: "Is Clean Architecture worth the extra effort?"

My answer: YES! But it wasn't without challenges.

What went well:

✅ 599 tests - Writing tests became easy (and fun!)
✅ Zero coupling - Changed parser implementation twice, no problem
✅ Added 4 EDIFACT versions - Clean separation made it trivial
✅ Confidence - I can refactor without fear

But there were challenges too:

⚠️ More files - Sometimes felt like overkill for simple features
⚠️ Initial velocity - First weeks were slower ("I could have hacked this in a weekend!")
⚠️ TypeScript DI complexity - No framework = manual wiring gets verbose
⚠️ Solo discipline - Easy to cut corners when no one is watching

The verdict? For a library like EDIFlow: Absolutely worth it! Every hour spent on architecture saved me days in maintenance.

For a throwaway script? Probably overkill.

(We'll dive into the honest pros & cons, with real examples, in Part 5!)

3. Why TypeScript? 💙

EDI parsing is complex. You're dealing with:

618+ message types (ORDERS, INVOIC, DESADV...)
Thousands of segment definitions
Complex validation rules
Delimiters, escape characters, special cases

Without type safety, this becomes a nightmare.

TypeScript Benefits for EDIFlow:

1. Type Safety for Complex Parsing Logic

// ❌ JavaScript - Runtime errors waiting to happen
const delimiters = {
  component: ':',
  element: '+',
  segment: "'"
};
delimiters.component = delimiters.element; // Oops! No error! 💥

// ✅ TypeScript - Caught at compile time
export class Delimiters {
  private constructor(
    public readonly component: string,
    public readonly element: string,
    public readonly segment: string
  ) {
    if (component === element) {
      throw new Error("Delimiters must be different!");
    }
  }
}

2. IntelliSense = Developer Happiness

// ✅ Auto-completion works!
const order = mapper.mapToBusinessObject(message);
console.log(order.documentNumber);        // IntelliSense suggests fields
console.log(order.parties.buyer.id);      // Type-safe navigation
console.log(order.lineItems[0].quantity); // No guessing!

3. Interface-Driven Design (Perfect for Clean Architecture!)

// Domain Layer - Just an interface, no implementation details
export interface IEDIParser {
  parse(message: string): EDIMessage;
}

// Infrastructure Layer - Implements the interface
export class EdifactMessageParser implements IEDIParser {
  parse(message: string): EDIMessage {
    // EDIFACT-specific logic here
  }
}

This is Dependency Inversion in action! The domain doesn't know about EDIFACT. The domain just knows "I need a parser."

4. Easy to Publish to npm

TypeScript compiles to JavaScript, so it works everywhere:

npm install @ediflow/core     # Works in Node.js
import { EdifactParser } from '@ediflow/core';  # Works in browsers (with bundler)

Plus, TypeScript generates .d.ts files automatically—users get IntelliSense out of the box!

5. Strong Ecosystem

Vitest for testing (fast, great DX)
tsup for building (zero config!)
TypeScript strict mode catches bugs early

TypeScript Made EDI Development Enjoyable

Before EDIFlow, EDI development was:

😫 Debugging runtime errors
🤷 Guessing what element[3] means
💥 Breaking changes at runtime

With TypeScript:

✅ Compile-time safety
✅ IntelliSense everywhere
✅ Refactoring with confidence

TypeScript isn't just a nice-to-have for EDIFlow. It's essential.

4. Why Open Source? 🌍

Learning in Public

I could have built EDIFlow as a private project. But I chose open source for several reasons:

1. Accountability

When you know others might read your code, you write better code.

No shortcuts. No "I'll fix this later." Everything has to be production-ready.

2. Community Feedback

Open source means:

🐛 Bug reports from real users
💡 Feature suggestions I never thought of
🤝 Potential contributors
📖 Documentation improvements

The best products are built WITH the community, not just FOR them.

3. Portfolio & Learning

Let's be honest: If I'm spending 100+ hours building this, I want to:

✅ Show it in my portfolio
✅ Get feedback from experts
✅ Help others with the same problem
✅ Build my personal brand

Open source is the ultimate resume.

4. Solving a Real Problem

I'm not the only one struggling with EDI libraries. By open-sourcing EDIFlow, I hope to:

Help developers new to EDI
Provide a modern alternative to legacy tools
Show that EDI can be developer-friendly

5. MIT License = Maximum Freedom

EDIFlow is MIT licensed:

✅ Use it commercially
✅ Modify it however you want
✅ No attribution required (but appreciated!)
✅ No strings attached

Why MIT? Because I want maximum adoption. The more people use it, the better it gets.

5. What is EDIFlow? 🚀

Okay, enough about motivation. What IS EDIFlow?

EDI = Electronic Data Interchange

Companies exchange business documents electronically:

Purchase Orders (ORDERS)
Invoices (INVOIC)
Shipping Notices (DESADV)
Inventory Reports (INVRPT)

Instead of paper, they send structured messages like:

UNH+1+ORDERS:D:96A:UN'
BGM+220+ORDER12345+9'
DTM+137:20240201:102'
...

EDIFACT = UN/EDIFACT Standard

EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) is the United Nations standard for EDI.

It's used globally, especially in:

🚢 Logistics & Supply Chain
🏭 Manufacturing
🏥 Healthcare
🏛️ Government

EDIFlow = Modern TypeScript Library for EDI

EDIFlow is:

✅ Parser - EDIFACT string → TypeScript objects
✅ Validator - 3-phase validation (Syntax → Structure → Business)
✅ Builder - TypeScript objects → EDIFACT string
✅ Mapper - Auto-convert to/from business objects
✅ Schema Exporter - Generate JSON Schema & TypeScript types

Built with:

Clean Architecture (Uncle Bob)
TypeScript (strict mode)
TDD (599 tests!)
Zero dependencies (core package)

And this is just the beginning! 🚀

Right now, EDIFlow supports EDIFACT (4 versions). But the journey continues:

🔜 X12 (ANSI ASC X12) - Coming soon!
🔜 More EDI formats - We're agile, we follow the flow!
🔜 Community-driven features - What does the community need?

The Clean Architecture foundation makes adding new formats easy. That's the power of good design!

Quick Example:

import { DIContainer } from '@ediflow/core';

// 1. Parse EDIFACT string
const container = DIContainer.getInstance();
const parseUseCase = container.resolve('ParseEDIUseCase');

const result = parseUseCase.execute({
  message: edifactString,
  standard: 'EDIFACT'
});

console.log(result.message.messageType); // "ORDERS"

// 2. Map to business object (type-safe!)
const mapper = container.resolve('BusinessObjectMapper');
const order = mapper.mapToBusinessObject(result.message);

console.log(order.documentNumber);         // "ORDER12345"
console.log(order.parties.buyer.id);       // "BUYER123"
console.log(order.lineItems[0].productId); // IntelliSense works!

// 3. Modify with type safety
order.lineItems[0].quantity = 150;

// 4. Build back to EDIFACT
const buildUseCase = container.resolve('BuildEDIUseCase');
const ediString = buildUseCase.execute({
  message: mapper.mapFromBusinessObject(order),
  standard: 'EDIFACT'
});

This is what "modern EDI" looks like. ✨

6. Project Stats 📊

Let me give you a sneak peek at what we've built so far:

Packages (npm)

Current (EDIFACT):

@ediflow/core - Parser, Validator, Builder engine (MIT)
@ediflow/edifact-d96a - D.96A (1996) - 89 messages (MIT)
@ediflow/edifact-d01b - D.01B (2001) - 155 messages (MIT)
@ediflow/edifact-d20b - D.20B (2020) - 178 messages (MIT)
@ediflow/edifact-d12a - D.12A (2012) - 196 messages (MIT, Prep)

Coming Soon:

@ediflow/x12 - ANSI ASC X12 support 🔜
More formats - We're agile, we follow where "Flow" leads us! 🌊

Current Total: 618 EDIFACT message types supported (and growing!)

Tests & Quality

✅ ~600 tests passing (unit + integration + e2e)
✅ ~90% test coverage (goal: 95%+)
✅ Clean Architecture - All layers tested independently
✅ TypeScript strict mode - No any types!
✅ Zero dependencies (core package)

Architecture

┌───────────────────────────────────────┐
│     Presentation Layer                │  CLI, API, UI (Future)
│                                       │
│  ┌─────────────────────────────────┐ │
│  │   Infrastructure Layer          │ │  Parsers, Repositories
│  │                                 │ │
│  │  ┌───────────────────────────┐  │ │
│  │  │   Application Layer       │  │ │  Use Cases, Services
│  │  │                           │  │ │
│  │  │  ┌─────────────────────┐  │  │ │
│  │  │  │   Domain Layer      │  │  │ │  Entities, Value Objects
│  │  │  └─────────────────────┘  │  │ │
│  │  └───────────────────────────┘  │ │
│  └─────────────────────────────────┘ │
└───────────────────────────────────────┘

Dependency direction: Always inward → → → →

Note: Presentation Layer (CLI, REST API, Web UI) is planned for future releases!

7. What's Coming in This Series? 🗓️

This is just Part 1 of 6! Here's what's next:

Part 1 (This Article): Why? ← You are here! ✅

Motivation & personal story
Why Clean Architecture?
Why TypeScript?
Why Open Source?

Part 2 (Next Week): Domain Layer Deep-Dive

Entities (EDIMessage, Segment)
Value Objects (Delimiters, Standard, Version)
Business Rules (ValidationRule, MandatoryRule)
Real code examples from EDIFlow

Part 3: Application Layer - Use Cases & Services

ParseEDIUseCase, ValidateMessageUseCase, BuildEDIUseCase
ComposableValidationService
DTOs & Dependency Injection
How orchestration works

Part 4: Infrastructure Layer & Monorepo Structure

Parsers (EdifactMessageParser)
Repositories (FileBasedMessageStructureRepository)
Why 5 packages? (Monorepo strategy)
TypeScript project references

Part 5: Presentation Layer - The Interface

CLI tools and commands
REST API design (planned)
Web UI vision (future)
How Presentation Layer stays clean
Dependency Injection from top to bottom

Part 6 (Finale): Lessons Learned & Future

Was Clean Architecture worth it? (honest answer!)
Performance analysis (benchmarks!)
Testing insights (600 tests!)
What I'd do differently
Roadmap & future plans

Each article: 1000-1800 words, deep technical dive with real code!

8. Conclusion & Call to Action 🚀

My Journey

EDIFlow is more than just a library. It's my journey of:

📚 Learning Clean Architecture by doing, not just reading
💙 Proving TypeScript is perfect for enterprise-grade libraries
🌍 Building in public and sharing the process
🔧 Making "old school EDI" developer-friendly
🌊 Following the Flow - Starting with EDIFACT, next X12, then... who knows? We're agile!

It's Not Perfect (Yet!)

I'm not claiming EDIFlow is perfect. I've made mistakes. I've refactored. I've learned.

And that's exactly what this series is about.

In the next 4 articles, I'll show you:

✅ What worked (spoiler: a lot!)
❌ What didn't work (also a lot!)
💡 How to apply Clean Architecture in TypeScript
🚀 Real code from a production-ready library

This is Pair Programming... with You!

I built EDIFlow with GitHub Copilot as my pair programming partner. Now I'm sharing the journey with you.

Follow along, and let's learn together!

🔗 Links & Resources

Try EDIFlow:

Join the Community:

💬 Discord: EDIFlow Community - Real-time chat & support
📣 GitHub Discussions
📧 Email: hello.ediflow@gmail.com

Read More:

💭 What Do YOU Want to Learn?

This series is for you. What topics should I cover?

Domain Layer patterns?
TypeScript DI without frameworks?
Testing strategies?
Performance optimization?

Comment below! 👇

📢 Next Up: Part 2 - Domain Layer

Next week, we'll dive into the Domain Layer:

How do Entities differ from Value Objects?
Why immutability matters
Real code examples from EDIFlow
TypeScript patterns that make Clean Architecture easier

See you next week! 🚀

If you found this helpful:

⭐ Star EDIFlow on GitHub
💬 Join our Discord
📖 Follow this series (click "Follow" on my Dev.to profile!)
🔄 Share with your network

Let's make EDI development great again! 😄

This article is part of the "Building EDIFlow: A Clean Architecture Journey in TypeScript" series. Follow along as we build a production-ready EDIFACT library from scratch using Clean Architecture principles.

Word Count: ~1,650 words

Reading Time: ~7 minutes

Series: Part 1 of 6

Coming Soon:

Part 2: Domain Layer Deep-Dive
Part 3: Application Layer
Part 4: Infrastructure & Packages
Part 5: Presentation Layer
Part 6: Lessons Learned