Domain-Driven Design of Large Software Systems (DDD), WS23

Domain-Driven Design of Large Software Systems (DDD) enables students to architect complex software systems from the ground up, using the DDD paradigm for designing loosely coupled software systems. The course focuses on the domain exploration and subdomain specification. Aspects of a technical architecture and the actual coding are not covered in this course.

Study Program and Module Description

Master Digital Sciences (specialization Software Architecture) (see also module description in the study program web page)

Begin/End and Scheduling

06.10.2023 - 05.01.2024. Organized as 7 - 8 (usually full-day) workshops; specific dates and agenda see below.

Location

The module takes place in presence. In exceptional cases (but only if explicitly communicated for the day) we'll switch to a remote option (video conference). If more than one location is listed here, please look at the respective time slot or workshop day (see bottom of this page), which location is used on which day. If there are no details given on this page, please check the other communication channels (e.g. Discord).

Room 1: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions

Room 2: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions

Video conference link: https://th-koeln.zoom-x.de/j/65794237439?pwd=ekFFaFJ0ZkU1dFRQUk41NjRXYnFIUT09 (only in exceptional cases and if explicitly communicated in advance for the day)

ILIAS/ILU Course for the Module

https://ilu.th-koeln.de/ilias.php?ref_id=85613&cmdClass=ilrepositorygui&cmdNode=xp&baseClass=ilrepositorygui

Registration for the Module

Please join this ILIAS/ILU course. Deadline is 12.10.2023. Please remember that you must additionally register for the exam via PSSO. The registration deadlines for this can be found on the F10 information pages of the TH Köln.

Maximum / Minimum Number of Participants

The maximum number of participants is 15. If there are less than 3 participants, the course cannot take place.

Miro Board used for documenting the EventStorming results, and the subsequent domain modelling results

During the module, you can use this Miro Board.

Discord Server for fast Communication

Discord has been proven as a very effective platform for information sharing, discussions, and consultations. Therefore, please join the ArchiLab Discord Server at https://discord.gg/YYNYb5whU8. Navigate to channel #rollenzuweisung and click on ddd. Then you automatically get access to the channel(s) relevant for this module.

Content

• Learning Outcome
• Methodology
• Structure of this Course
• Documentation
  • Final Presentation
• Grading (Based on a Points Scale Between 0 and 3)
  • Individual Contribution
• Workshops
  • Fri 06.10.2023, 10:00 - 14:00: Kickoff
  • Fri 27.10.2023, 10:00 - 17:00: EventStorming Trial Workshop
  • Fri 10.11.2023, 10:00 - 17:00: Bounded Context Trial Workshop
  • Fri 17.11.2023, 10:00 - 17:00: C4 Model Trial Workshop
  • Mon 27.11.2023, 10:00 - 17:00: Hackathon Nov23, day 1 - EventStorming
  • Tue 28.11.2023, 10:00 - 17:00: Hackathon Nov23, day 2 - Bounded Context formalization
  • Fri 15.12.2023, 10:00 - 17:00: Documentation Review (EventStorming and bounded contexts) and C4 Model preparation
  • Thu 04.01.2024, 10:00 - 17:00: Hackathon Jan24, day 2 - C4 Model Workshop
  • Fri 05.01.2024, 10:00 - 17:00: Hackathon Jan24, day 3 - Documentation Finalization and Presentation
  • Wed 21.02.2024, 16:00 - 18:00: Q&A Session for Final Presentation and Paper
  • Fri 23.02.2024, 10:00 - 17:00: Final Presentation on GP Presentation Day

Learning Outcome

This module attempts to walk you through the design process for a relatively complex software system, by creating a domain-specific design for the problem. Modern software architecture means that you are close to coding. Therefore, we will have a real software development case study in this module. See below. You will not have to write code in this module, but you need to know how software development teams work, and what their needs and their deliverables are.

As a experienced programmer, architect, or business analyst I can design a reasonably complex greenfield application for a multi-team development setup, using the domain-driven design paradigm,

by me ...

• conducting an EventStorming workshop, in order to capture the business domain,
• evaluating the domain flows and defining appropriate bounded contexts for the teams,
• creating a domain model, using the appropriate design elements,
• defining a high-level C4 model, using the C4 modelling approach,
• documenting the results of the design process in a paper and a presentation,
• reflecting the pros and cons of that particular design method,

so that I can make sure that I have a sound, sustainable high-level architecture for my business domain.

Methodology

Domain-Driven Design (DDD) is a concept framework rather than a design method. In order to give this course a practical, hands-on approach, we will use the DDD Starter Modelling Process as a process model. This is a multi-phase process, which we will divide in the three parts listed below. The list also contains the artifacts that we will create in this course (as indented bullet points).

1. EventStorming
   • Workshop concept
   • EventStorming result documentation
2. Bounded Contexts
   • Domain Message Flow Modelling
   • Bounded Context Canvas
   • Context Map
   • Feedback from the case study partner team
3. C4 Model
   • Aggregate Design Canvas
   • C4 Level 1 system diagram
   • C4 Level 2 container diagram
   • Feedback from the case study partner team

Structure of this Course

We will form three subteams - one for each of the three phases. The subteams will perform an in-depth study of the the artifacts they are responsible for. They will prepare a trial workshop for their phase, so that all participants of this course can get a hands-on experience of the method. The trial workshops will be facilitated by the subteams, with the other course participants as participants. I will coach and support the subteams.

In the second part of the course, we will apply the methods to a real case study. Getting more familiar with Domain-Driven Design concepts should be a hands-on experience. The case study will be a Guided Project working on an ecommerce application.

Documentation

All of the artifacts mentioned above have to be documented. The documentation of the workshop preparation and results (trial and real) is expected in digital format as a paper. I have created an Overleaf project with a template for this paper. Latex will be used, since this a de-facto standard for papers and reports in the computer science community; in addition, Overleaf is great for collaborative editing. A free account is sufficient for our purposes.

Here is this detailed template as PDF. In addition, I expect a contribution table (e.g. as separate Excel sheet), listing each course member’s contribution to the various parts of the documentation.

Final Presentation

The final presentation should not be just a repetition of the results in the case study document. Instead, the presentation will tackle the following reflection topics. The course participants should register in small groups for one of the questions.

• Registering is done via ILU. Please join one of the subgroups you find at this link.
• Each “sub-presentation” can be between 10 and 20 min long. After 20 min, there will be a hard cut, for the sake of time management.

These are topics you can choose from. Feel free to propose topics of your own (but I will only accept them if they are on par with the given topics, in terms of difficulty and scope).

1. A Helicopter View on the Whole Design Process

We have roughly followed the recommendations by the DDD Crew, and their selection of methods. How would you assess this after having completed the course? What elements would you use in your own real-life projects, what is missing, what other elements could be added (maybe instead of steps we have done). Evaluate the literature and online sources for feedback and assessments of the DDD Crew material and selection, and compare this to your own experience.

2. Best Possible Case Study for DDD Course

Our case study in the DDD project was also a TH Köln module (a Guided Project). Assume that we had a real industry partner with a real-life project as a case study. What are the requirements, the caveats, the do’s and don’ts here? Just keep in mind that industry partners have their own timelines and needs. Please sketch how the DDD course could be organized with such an industry partner on board (e.g. which workshops in which order …). What obligations would the partner have to fulfill?

3. Maximum Benefit of Event Storming Workshops

How can you ensure that Event Storming has the maximum benefit for a software development project? In our course, it seemed that there was some kind of disconnect between the Event Storming, and the subsequent steps. How could you avoid this?

Evaluate the literature and online sources for Good Practice recommendations, and compare them to our experiences in this course. What would you do differently in a real-life project? And what should the DDD course do differently next time?

4. Domain Message Flow Diagrams without “Request / Response” Bias?

When designing Domain Message Flow Diagrams, there were a lot of discussions about how messages should be designed. Initially, many diagrams followed a traditional request / response pattern, and “chained” the messages from one bounded context to the next. Gradually, we moved to a more event-oriented pattern, where events are published and then consumed by whatever bounded context needs it.

How could you achieve - in the next DDD course, as well as in a real-life project - that this doesn’t happen in the beginning? Or is it something you cannot avoid? What would the team need as preparation, what discussions or workshops would help?

5. What are Really Useful Canvases? Do they exist?

We had a number of canvases in our methods. How useful did you find them? Can they be more than just repetition? What purpose can they have in real-life projects? What canvas(es) are really useful? Evaluate the literature and online sources for Good Practice recommendations, and bring in your own experience. If needed, feel free to propose an own (draft) canvas design.

6. How Could we Improve the Workshop Structure for this Course?

In this course we have been using a structure consisting of trial workshops for each block of methods, followed by workshops covering the actual case study. Can this structure be improved? What were the benefits, and what were the shortcomings? Please include the opinions and experiences of your peers in the course in your presentation, in a lightweight fashion, e.g. by a survey. Sum up your results by proposing an updated workshop structure for this course in the next semester. Please be realistic in timelines and boundary conditions.

Grading (Based on a Points Scale Between 0 and 3)

The module grade consists of several partial grades for the artifacts listed above, each based on a points scale between 0 and 3.

Grading Aspect	Contribution	0 Points	1 Points	2 Points	3 Points
Trial Workshop	15%	The methods are either misunderstood, not covered, or randomly applied. The workshop has either not taken place, or its preparation looks ad-hoc. If the workshop has taken place, it has run in a completely chaotic fashion, without achieving goals. All in all, commitment and effort (willingness to go the extra mile, …) are unacceptable.	The methods are only partially or superficially researched, possibly with major omissions. Their application is somewhat random at times. The workshop's preparation leaves a lot of room for improvement (trial workshop's setup / case study workshop taking up learnings from the trial). Workshop preparation seems sloppy and superficial. The workshop itself has been run in a somewhat random and/or chaotic fashion at times. All in all, commitment and effort (willingness to go the extra mile, …) are below average.	The methods are mostly well researched and by and large correctly and comprehensively applied. The workshop is adequately prepared (the trial workshop's setup has been researched and reasoned, and the case study workshop used some of the learnings from the trial). Workshop preparation (e.g. cheat sheets for the trial workshop) was ok, with some room for improvement. The workshop itself has mostly been run well, with moderator roles from the team. All in all, commitment and effort (willingness to go the extra mile, …) are on an average level.	The methods are fully researched and comprehensively and correctly applied. The workshop is thoroughly prepared (the trial workshop's setup thoroughly researched and reasoned, and the case study workshop with incorporated learnings from the trial). Workshop preparation (e.g. cheat sheets for the trial workshop) doesn't leave room for criticism. The workshop itself has been run professionally, with active moderator roles from the team. All in all, commitment and effort (willingness to go the extra mile, …) are well above average.
Case Study Workshop	10%
Documentation of Trial Workshop (as initial chapter of the DDD paper)	10%	Documentation of the trial workshop is either missing, or unusable.	Documentation of the trial workshops only partially captures the preparation and lessons learnt from the trial, and contains a lot of errors and omissions.	Documentation of the trial workshops mostly captures the preparation and lessons learnt from the trial.	Documentation of the trial workshops fully captures the preparation and lessons learnt from the trial.
Contribution to the case study, and its documentation	55%	The documentation doesn't reflect results and relevant practical learnings from the case study, nor does it contain scientific results, and no relevant / valid sources. The artefacts described make little or no sense. The level of effort and commitment in the case study and the documenting paper are unacceptable, and/or reflects an alarming unfamiliarity with practical and scientific work. Editorial and formatting aspectsseemingly have not really been addressed at all. Reference list missing or unusable.	The documentation presents at least some results and practical learnings from the case study and some valid research, amongst less relevant or valid parts. A list of sources exists, but is not extensive or adequate. Same for the reflection of the team's activities. The artefacts described make some sense, but leave a lot of room for criticism. The case study and its documentation reflect an rather poor level of effort and commitment, or a lack of skills in scientific work. Editorial and formatting aspects show major flaws. Reference list is very short, and does not reflect a lot of own research.	The documentation presents results and practical learnings from the case study, and some valid research, with an appropriate list of sources found and evaluated, and a good reflection. The case study and its documentation reflect an avarage level of effort and commitment. Editorial and formatting aspects show only minor flaws. Reference list presents a good overview of relevant sources.	The documentation presents immaculate summary of case study results and practical learnings from the case study, as well as research with an extensive list of sources, and a valid reflection. The artefacts described leave no room for criticism. The case study and its documentation reflect a high level of effort and commitment. Editorial and formatting aspects are without flaws. Very comprehensive list of sources, showing a lot of own research.
Final Presentation	10%	Presentation is not an acceptable summary of the project. Examples are missing or do not make sense. Presentation is unacceptably poorly coordinated.	Presentation summarizes only some key aspects of the project. Examples are inadequate, or poorly match the presentation. Presentation has many style breaks and inconsistencies, but with still recognizable "common thread".	Presentation summarizes the key aspects of the project in an somewhat understandable manner. The selected examples mostly fit to the statements of the presentation. Presentation is appropriately coordinated, with individual breaks in style and inconsistencies.	Presentation summarizes all relevant aspects of the project in easily understandable fashion. The selected examples illustrate the statements of the presentation. Presentation is very well coordinated and is perceived by the viewer "as one".

Individual Contribution

As a default, I assume that each team member contributes an equal share to the team project. However, if I have indications that this is not the case, I reserve the right to adjust the individual grades accordingly. In such a case, I will modify the team points for the individual score according to the following table.

Individual Contribution	< 30%	30 … 80%	80 … 100%	> 100%
Level of individual contribution to team efforts	The student was hardly involved in any interactions at all within the team.	The student was only involved in team interactions on a few occasions.	The student has been visible to an average degree in the team (guiding others, leadership tasks, providing assistance, contributing to professional discussions, etc).	The student has been exceptionally visible in the team through guidance of others, leadership roles, assistance, contributions to professional discussions, and the like.

This concerns the following the workshop and the final presentation aspects, which are group grades. The case study grade points are based on individual contributions, as per effort matrix.

Workshops

Fri 06.10.2023, 10:00 - 14:00: Kickoff

We discuss the goals, structure, organizational details, and grading for this module. In addition, you get an introduction to the preconditions for this course and pre-courses, where applicable.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

You can start with this module.

Please watch the following video(s) beforehand

Agenda

• 10:00 - 10:30:  Introduction Round
  • Every participant introduces her/himself
  • What is your knowledge level wrt. coding and DDD concepts?
  • What are your expectations?
• 10:30 - 11:15:  Organisation of the module
  • Goal of this module
  • Structure
  • Organizational details
  • Grading
• 11:30 - 12:15:  The DDD journey in a nutshell
  • Sketching the road ahead
  • Brief introduction into the sequence of the design elements
  • Ecommerce case study briefly explained
• 12:15 - 13:00:  Lunch Break
• 13:00 - 14:00:  Team formation and next steps
  • Task details for each subteam
  • Team formation - please give your vote here (green means "I want to be in this team", yellow means "I can live with being in this team", red means "I don't want to be in this team, if possible")
  • Questions, next steps

Task until next workshop

• For the EventStorming team, prepare the trial EventStorming workshop
• For the other teams, read material and start working on the trial workshops

Fri 27.10.2023, 10:00 - 17:00: EventStorming Trial Workshop

We try out the EventStorming method in a trial workshop, and reflect on the results. The goal is to make all of you familiar with this method, before we apply it to the real case study. This trial workshop will be prepared by a dedicated "EventStorming" subteam. This subteam will also facilitate the trial workshop as moderators, with the other course members as participants. I will coach and support the moderators.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

We have an understanding how this method works, of its strengths and limitations.

Agenda

• 10:00 - 10:30:  Intro on the method and the trial business domain
  • Business domain for the trial
  • Intro to the method
• 10:30 - 12:30:  EventStorming - Big Picture
• 12:30 - 13:30:  Lunch Break
• 13:30 - 15:00:  EventStorming - Event Clustering
• 15:00 - 16:00:  Documentation
  • Create EventStorming result documentation (Miro board)
• 16:00 - 17:00:  Reflection on the results and the method

Fri 10.11.2023, 10:00 - 17:00: Bounded Context Trial Workshop

We evaluate the EventStorming results and derive bounded contexts (the blueprints for service boundaries) from them. As for the EventStorming, this is a trial workshop, prepared and facilitated by a dedicated "bounded context" subteam. This subteam will also facilitate the trial workshop as moderators, with the other course members as participants. I will coach and support the moderators.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

We have an understanding what bounded contexts are, and how to derive them from the EventStorming results.

Agenda

• 10:00 - 11:00:  Guest Lecture "Architecture modernization with DDD, event storming and more" (Halil Hancioglu, Opitz Consulting)
  • Domain-driven design (DDD) is often used to create a domain-driven architecture. In combination with a collaborative method such as EventStorming (ES), this can quickly help to create a solution picture and promote communication in large projects. Both methods can be helpful as tools in the architect's toolbox to break down a monolith into a distributed system. However, this alone is not enough to modernize. In this guest lecture, the speaker reports on the procedure for modernizing a monolithic system in the context of e-mobility with the help of DDD, ES and other tools.
  • Halil Hancioglu works as a Senior Solution Architect for OPITZ CONSULTING Deutschland GmbH. He has many years of experience in the creation of individual enterprise applications and the introduction of DevOps practices. His strengths lie in the analysis and restructuring of architectures with a special focus on modern IT operations.
• 11:00 - 11:30:  Introduction into the overall DDD design process, and specifically Bounded Context specification
  • Lecture "What happens next?" - Based on the Domain-Driven Design Starter Modelling Process
• 11:30 - 16:00:  Bounded Context Trial Workshop
  • Complete the EventStorming model, adding actors, pivotal events, aggregates, and commands
  • Define bounded contexts
  • Split group to for working on the bounded contexts
  • Identify core / generic / support domains
  • Do Domain Message Flow Modelling
  • Create Bounded Context Canvas for each bounded context
  • Create Context Map for the whole landscape
  • lunch break in between
• 16:00 - 17:00:  Final round to discuss the results
  • Summing up and reflecting the artifacts created
  • Reflection on results and the design process

Fri 17.11.2023, 10:00 - 17:00: C4 Model Trial Workshop

Based on the bounded contexts, we will now create a high-level C4 model. This is a trial workshop, prepared and facilitated by a dedicated "C4 model" subteam. This subteam will also facilitate the trial workshop as moderators, with the other course members as participants. I will coach and support the moderators.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

We understand how aggregates are a key to design service components, and how to create a high-level C4 model from the bounded contexts and their aggregates.

Agenda

• 10:00 - 11:00:  Introduction into Aggregate Canvas and C4 modelling
• 11:00 - 16:00:  C4 Model Trial Workshop
  • Split group to for working on the aggregates
  • Create an Aggregate Canvas for each major aggregate
  • C4 Level 1 system diagram, jointly done by all the teams
  • C4 Level 2 container diagram, seperately for each bounded context
  • lunch break in between
• 16:00 - 17:00:  Final round to discuss the results
  • Summing up and reflecting the artifacts created
  • Reflection on results and the design process

Mon 27.11.2023, 10:00 - 17:00: Hackathon Nov23, day 1 - EventStorming

We will now apply the methods we learnt and practiced in the trial workshops to the real case study, a Guided Project. This project works on implementing an ecommerce system, with a number of bounded contexts. This will be our business domain. We will start with EventStorming. Since both the DDD course and the Guided Project team will be part of the Hackathon event in the InnovationHub, we will have the opportunity of close interaction with the development team from the Guided Project all day. The EventStorming team will lead and moderate this session, with me supporting and coaching. The other DDD participants will act as business experts.

Workshop Location

Room: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions.

Goal of the day

We have a good understanding of the ecommerce business domain that the Guided Project, have collected a comprehensive set of business events, and clustered them into candidates for bounded contexts.

Tue 28.11.2023, 10:00 - 17:00: Hackathon Nov23, day 2 - Bounded Context formalization

Based on the previous day's EventStorming results, we will now derive bounded contexts from them. We will use the methods learnt in the trial workshop - Domain Message Flow Modelling, Bounded Context Canvas, and Context Map. The bounded context team will lead and moderate this session, with me supporting and coaching. The DDD participants will work in subteams, focusing each on a specific bounded context.

Workshop Location

Room: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions.

Goal of the day

We have a good understanding of the bounded contexts for the ecommerce business domain, and have documented them in a comprehensive way using the formats learnt in the trial workshop.

Task until next workshop

• Paper format clarified per subteam
• Paper contains the results of the EventStorming and bounded context workshop (EventStorming results, bounded context canvas, domain message flow modelling, context map)

Fri 15.12.2023, 10:00 - 17:00: Documentation Review (EventStorming and bounded contexts) and C4 Model preparation

We will review the documentation of the EventStorming and bounded context workshops, by a mutual review process (subteam A reviewing subteam B's results, B reviews C, and C reviews A). In addition, we will prepare the C4 model workshop by analysing the Guided Project's code base.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.

Goal of the day

The final workshop for the C4 model is well be prepared, and the documentation of the earlier artifacts (EventStorming results and bounded context documentation) is in good shape.

Task until next workshop

• Prepare the C4 model workshop

Thu 04.01.2024, 10:00 - 17:00: Hackathon Jan24, day 2 - C4 Model Workshop

We will now create a high-level C4 model for the ecommerce system that the Guided Project is working on. Again, both the DDD course and the Guided Project team will be part of the Hackathon event in the InnovationHub, so we can discuss the model with development team on site. The C4 model workshop will be prepared and facilitated by the "C4 model" subteam. I will coach and support the moderators.

Workshop Location

Room: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions.

Goal of the day

The Aggregate Canvases and the C4 Model has been created, and the results are documented to the extent needed to give a brief presentation the next day.

Fri 05.01.2024, 10:00 - 17:00: Hackathon Jan24, day 3 - Documentation Finalization and Presentation

The documentation for the ecommerce application of the Guided Project will be finalized, and the results will be presented to the Guided Project team (and to the other hackathon participants).

Workshop Location

Room: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions.

Goal of the day

The course artifacts are ready to be submitted, with only minor tasks remaining.

Wed 21.02.2024, 16:00 - 18:00: Q&A Session for Final Presentation and Paper

In this session, you can clarify questions about the final presentation. I don't expect to see your presentation beforehand.

Workshop Location

Video conference link: https://th-koeln.zoom-x.de/j/65794237439?pwd=ekFFaFJ0ZkU1dFRQUk41NjRXYnFIUT09 .

Goal of the day

All set for your presentation, and for submitting the paper.

Fri 23.02.2024, 10:00 - 17:00: Final Presentation on GP Presentation Day

You present your reflections on this courses (detailed times see agenda for the day)

Workshop Location

Room: Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also detailed directions.