Video summary

🚀 Clase 01: Arquitectura de Software | Maestría UNMSM

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

1) Course purpose and instructor framing

  • The instructor introduces the “Software Architecture” course for a Master’s program (UNMSM).
  • He shares personal credentials (also holds a Master’s from San Marcos) and explains that the course will integrate:
    • academic architecture methods, and
    • real-world industry practices drawn from students’ daily experiences across companies.

2) Student introductions (context for how the course will be received)

  • Students briefly present their backgrounds and experience with different architectures, such as:
    • monolith, MVC, layered/hexagonal, clean architecture, microservices.
  • Common themes include:
    • Architecture experience ranges from practical implementation to theoretical exposure.
    • Many students have worked in banks, public sector, mining, GIS systems, and other domains.
    • Several students are specifically interested in:
      • microservices vs modular monolith,
      • clean/hexagonal architecture,
      • working with legacy systems,
      • event-driven patterns and CQRS/event sourcing,
      • cloud deployment and scalability.

3) Core constraint / “how you will build the project”

The instructor sets explicit project constraints for the course final demonstration:

  • Primary required methodology

    • Domain-Driven Design (DDD) must be applied in the course project.

  • Event-driven requirements inside DDD

    • Use domain events (important facts that occur in the domain).
    • Publish/register those domain events through a message broker.
    • Communication is asynchronous, so the project must handle eventual consistency (not immediate consistency).

  • Communication style (demo requirement)

    • Demonstrate asynchronous communication using message passing via domain events.
    • Explain/implement how systems stay consistent under eventual consistency.

  • Design choice allowed (not a restriction)

    • The final architecture can be implemented as either:
      • microservices, or
      • modular monolith.
    • The instructor emphasizes modular monolith as a trend when microservices management becomes complex at large scale.

4) Patterns/topics the course will cover (as part of DDD + event-driven architecture)

The instructor previews key topics they will implement and evaluate:

  • DDD + Domain Events + Message Broker + Eventual Consistency

    • Domain events trigger async communication between domains/systems.
    • Event-driven architecture is central.

  • CQRS (Command Query Responsibility Segregation)

    • Separate write and read responsibilities.
    • Works alongside eventual consistency and event-driven design.

  • Event Sourcing (with projections)

    • System state is represented via events rather than current state only.
    • Reads are produced via projections generated from those events.

  • Possible hybrid consistency approach

    • The course encourages asynchronous patterns for demonstrations, while conceptually allowing a mix where some parts could be immediate-consistency and others eventual.

5) Course structure and deliverables

The syllabus is organized by units and weeks, increasing emphasis on practical work:

  • Cycle 1 (fundamentals)

    • Covers architecture fundamentals and the design process:
      • Architectural design process and drivers
      • Quality attributes
      • Architectural requirements
      • Architectural design method: ADD (Attribute-Driven Design)

  • Week 8 deliverable

    • First progress report / advance of the final project.
    • Students form groups (3–4 groups total; group size depends on enrollment).

  • Weeks 9–11 (practical implementation activity)

    • Implement patterns and concepts in code/proofs of concept:
      • event-driven architecture
      • DDD concepts
      • CQRS
      • event sourcing
      • additional engineering practices (e.g., clean code)
    • Deliverable emphasis: demos should include not only architecture diagrams, but also “proofs of concept.”

  • Unit 3 (cloud deployment)

    • Weeks roughly 12–13 (described as a two-week cloud-focused topic)
    • Deploy proofs of concept to:
      • Amazon AWS
      • Microsoft Azure
      • Google Cloud

  • Unit 4 (hybrid solutions)

    • Hybrid solutions involving on-prem/cloud premises.

  • Week 15

    • Presentation of final work.

  • Week 16

    • Final exam.

6) How the architecture will be designed (methodology)

A major academic method is highlighted:

  • ADD (Attribute-Driven Design)
    • Students design architecture using architectural “drivers.”
    • The method helps define:
      • architectural drivers,
      • quality attributes,
      • scenarios for quality attribute evaluation,
      • architectural diagram sketches.
    • Students then apply the C4 model (for diagrams) and may use UML/other diagramming conventions.

7) Evaluation, performance, and participation (important rules)

The instructor explains grading mechanics:

  • Performance grade (participation-based)

    • 15% assigned individually based on in-class participation and small tasks.
    • If students are given small activities (e.g., edits to models/diagrams or small C4 changes) and don’t submit evidence, it affects their score.

  • Weighting across the course

    • Week 8 partial work: 20%
    • Final project (Week 15): 30%
    • Final exam (Week 16): 35%
    • Minimum passing grade mentioned: 14
    • Absences policy: >30% absences leads to failing the course.

  • Final exam format

    • Typically a virtual exam consisting of a case, where students apply course concepts to answer questions.

8) Conceptual foundations taught in the second part of the session

The instructor begins conceptual lectures about software engineering and architecture:

  • Software engineering definition (formal)

    • A systematic, disciplined, quantifiable approach applied across the software lifecycle:
      • requirements → development,
      • operation,
      • maintenance.

  • Why software engineering exists

    • Avoids ad hoc/disordered development.
    • Controls complexity via methods, standards, and metrics.

  • Key distinction: architecture vs design

    • “Design” can be ambiguous, so it is treated as:
      • architecture (high-level structure and integration between components/modules and quality attribute satisfaction),
      • detailed design (internal component-level implementation, such as classes and methods).
    • Emphasis statement:
      • “All architecture is design, but not all design is architecture.”

  • Quality attributes as architectural drivers

    • Quality attributes represent non-functional requirements.
    • Architecture should be judged by whether it satisfies its architectural drivers and quality attribute scenarios.
    • Trade-offs are inevitable among quality attributes depending on context and constraints.

  • Architecture as structures

    • Architecture is framed as a set of structures (elements, relationships, properties) used to satisfy drivers.
    • Internal implementation details belong more to design than architecture.

Methodology / instructions (detailed bullet format)

A) Build the final project using required constraints

  • Apply Domain-Driven Design (DDD) to the project.
  • Identify and model domain events (important facts in the domain).
  • Publish/store those domain events using a message broker.
  • Implement behavior with asynchronous communication:
    • demonstrations must show event-driven message passing.
  • Handle eventual consistency:
    • ensure the system remains correct over time under async updates.
  • Decide (allowed option) the deployment/structure style:
    • either microservices
    • or modular monolith
  • Demonstrate CQRS + Event Sourcing in the implementation/proof of concept:
    • separate read/write paths (CQRS),
    • store state as events,
    • generate read models via projections (event sourcing).

B) Use architecture design approach in the course

  • Design architecture using ADD (Attribute-Driven Design):
    • define architectural drivers such as:
      • quality attribute scenarios,
      • constraints,
      • concerns,
      • primary functionality,
      • purpose/value to the customer.
    • produce architectural diagram sketches.
  • Use the C4 model (and UML/other diagrams if needed) for documentation.

C) Deliverables and reporting cadence

  • Create project groups (3–4 groups max, depending on enrollment).
  • By Week 8:
    • submit the first progress report (advance of final project).
  • Weeks 9–11:
    • implement proofs of concept demonstrating architectural patterns in code.
  • Cloud phase:
    • deploy proofs of concept to AWS/Azure/Google Cloud.
  • Week 15:
    • present final work.
  • Week 16:
    • take the final exam (case-based virtual assessment).

D) Participation tasks (performance grade)

  • Participate actively in class Q&A and assigned micro-activities.
  • If tasks are assigned (e.g., small edits to C4 diagrams/models):
    • submit evidence (e.g., repository updates).
  • If evidence is not submitted, it may impact the 15% individual performance grade.

Speakers / sources featured (identified)

Speakers / people

  • Course instructor / professor (name unclear in subtitles; referred to repeatedly as “professor/EfraĂ­n/EfraĂ­n”)
  • Chano HuamĂłn Landa
  • Daniel Palomino
  • Diego Aliaga (also shown as Diego Oiaga / Aliaga)
  • Giovana Guaita
  • J. Felix / Hans Christian (shown in subtitles)
  • Iván Paredes
  • Jimena Ruiz
  • Lino Ramos
  • MartĂ­n PĂ©rez
  • Micah Quintanilla (also “Micah Titus Quintanilla”)
  • Nestor Hernandez
  • Orlando Vera
  • Robert Vivar (also shown as “Rob Ibar”)
  • Robin Ortiz
  • Ronald Alexander Guillermo Navarro
  • Aurelio Yoshio (also shown as Aurelio Oniku / Onuki)
  • RubĂ©n Roque
  • Billy Aguiña Curagua
  • Fredy Ugarte / Frediailla
  • Marcelo LĂłpez (also shown as Marchelo LĂłpez)
  • Victor Alexis (also shown as Victor)
  • EvĂ­t Guapayá (also shown as Evit/Evid/“Evita”)
  • Adrián Antonio / Adrian
  • Franklin / Franklin Arturo
  • Rodolfo Fernández Hamán
  • Cruzcla Quispe (also shown as Cruz/“Cruzcla”)
  • Y. Quintana Yang (mentioned as not present)
  • Additional student voices: several other attendees are referenced, but names/audio presence are unclear due to subtitle errors.

Institutional / source references (books/standards/institutions)

  • IEEE / SEI: Software Engineering Institute (affiliated with Carnegie Mellon University)
  • IESE / Institute of Engineering of Software (referenced for ADD and ADD method)
  • Carnegie Mellon University
  • C4 model
  • UML
  • ADD (Attribute-Driven Design) method
  • SWEBOK (Software Engineering Body of Knowledge) including:
    • v3 (noted as free download),
    • v4 (noted as draft/beta)
  • Designing Software Architectures (Humberto Cervantes and Rick Kasman) — second edition (recommended/used in the course)
  • Mentioned standards/history:
    • ISO/IEC 12207 (software lifecycle processes)
    • Agile Manifesto (2001)

Places / platforms mentioned

  • Microsoft Teams (materials, syllabus location, recordings)
  • Cloud providers: AWS, Azure, Google Cloud
  • Message broker (specific broker name not clearly stated in the summary)

Original video