https://datatweets.com/courses/software-engineering/design-architecture-and-oop/Recent content in Design, Architecture & OOP on DATATWEETSHugoenCopyright (c) 2025 DatatweetsSun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-1-software-design-and-architecture/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-1-software-design-and-architecture/This lesson explains the difference between architecture (the shape of the whole system) and design (the shape of one component), then walks through three concrete patterns: layered architecture, MVC, and the monolith-versus-microservices decision. Every example uses Ledgerly’s own classes — InvoiceController, InvoiceService, InvoiceRepository, and a billing service split out to handle its own scaling needs. By the end, you can explain why Ledgerly’s three-person team should stay a monolith today, and what would have to change before splitting out billing makes sense.https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-2-object-oriented-programming-in-practice/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-2-object-oriented-programming-in-practice/This lesson moves past the basics of classes and objects into the OOP techniques that shape real designs: inheritance, polymorphism, and the choice between composition and inheritance. Ledgerly’s PaymentGateway family shows how StripeGateway and PayPalGateway inherit shared behavior and override the rest, and a composed Invoice class shows why building an object from smaller collaborators often beats a deep class hierarchy. Encapsulation and abstraction, covered in Module 1, get only a brief mention here.https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-3-design-patterns-creational-and-structural/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-3-design-patterns-creational-and-structural/This lesson covers six proven design patterns split into two families: creational patterns (Factory Method, Builder, Singleton) that control how objects get created, and structural patterns (Adapter, Decorator, Facade) that control how objects combine into larger pieces. Every example builds on Ledgerly’s invoicing code — picking the right PaymentGateway by name, assembling a complex Invoice step by step, wrapping a third-party SDK, and stacking discounts and late fees on a total. By the end, you can recognize each pattern’s shape and choose the right one for a given problem.https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-4-design-patterns-behavioral/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-4-design-patterns-behavioral/This lesson covers three behavioral design patterns using Ledgerly, a small invoicing app, as the running example. You will swap interchangeable discount rules with Strategy, notify email, SMS, and audit-log listeners with Observer when an invoice is paid, and queue reversible billing operations with Command. Every example builds directly on Ledgerly’s existing Invoice and PricingEngine classes.https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-5-guided-project-architecting-ledgerlys-domain/Sun, 05 Jul 2026 09:00:00 +0200https://datatweets.com/courses/software-engineering/design-architecture-and-oop/lesson-5-guided-project-architecting-ledgerlys-domain/In this guided project you close Module 2 by taking one real Ledgerly feature, refunds, from an open design question to tested code. You decide where refund logic should live relative to billing, design a RefundPolicy class hierarchy for Stripe and bank-transfer refunds, apply the Strategy pattern so RefundService never checks a gateway name with an if-statement, and apply the Observer pattern so a customer notification and an accounting ledger entry both fire without RefundService knowing either one exists. A real Python test then proves the design by swapping in fake observers.