Professors
Danilo Pianini
Giovanni Ciatto
Prioritize the forum
- All technical questions
- Any other non-personal question
When using the email
- Include both teachers, always
Office hours
Resources
- These slides should contain everything you need
- code examples produced during the lecture will be available right after
- most code is already on GitHub
Slides will be produced with a rolling release model.
Books
No mandatory books, but there are both:
- Recommended readings
- Additional useful books
On the course webpage
Organization
- Thursday 10:00–13:00 (3h) — Room 2.5
- Friday 14:00–17:00 (3h) — Lab 4.2
Changes will be published on the forum
Goals
- Learn how to design software systems, following a domain-, model-, and/or test-driven approach
- Zero-overhead from domain definition to executable code
- Agile development practices, DevOps philosophy
- High automation + technical excellence
- Understand analogies and differences among programming platforms
Prerequisites
- Knowledge of Java; Scala is a nice-to-have
- Minimal ability with
git
- initializing a repository and managing its options
- committing
- branching and merging
- fetching and pushing
- A curious mindset
- Never stop when it works, stop when you know why it does
- This is especially true in the LLM era
Exam
Discussion of a group project
-
Must feature:
- Domain-driven design
- Clear development process and DevOps practices
- Full-scale automation
- Including continuous integration and delivery
- Deploy automation via containerization and/or orchestration
- Technically involve 2+ target platforms
- e.g., JVM, NodeJS, Python, C, C++, Rust, Go, etc.
- two targets are different if they run on a different runtime (e.g., native + JVM)
- two targets are likely different if they use different build systems (but there are exceptions: Scala/sbt + Java/Gradle are not considered different targets)
-
Can be a joint effort with other courses
- We care about the domain modeling and the application of DevOps techniques
- You can pick a project of another course, apply them there, and it is fine for SPE
-
Can be a project created for SPE alone
- If you are short on ideas, we can help :)
-
Can be a project that covers SPE + thesis
“Project work”
The exam’s project can be developed as a “project work”, namely,
a project whose requirements are provided by a real-world company,
which acts as the client.
- The students will interact with the company to apply Domain-Driven Design on a real piece of software.
- The project will be open source
- All the features required for a “normal” exam project still hold
It is an opportunity to learn by doing in a context closer to the industry.
Available project works will be posted on the course site on https://virtuale.unibo.it/
Final project quality checklist
It is strongly recommended to check out https://www.bestpractices.dev/en, applying first all the relevant items there.
DVCS
- Adoption of a DVCS
- Consistently following some commit convention (e.g. Conventional Commits)
- Consistently following some branching/forking convention
- The branching convention is adequate to the team size and type
- Commits are consistent and coherent, i.e. only what should be committed together has been committed together
- reasonable, justified merging strategy
Versioning
- Web API specifications (e.g. OpenAPI, Swagger), if any, are versioned
- Web server routes (if any) are versioned
- Releases are versioned
- Version numbers are computed automatically
- Multiple releases exist
Final project quality checklist
Project structure
- The project dependencies are formally declared (incl. locking where reasonable)
- The project dependencies are updated automatically where possible
- The project directory includes build automation
- The build automation technology of choice is adequate for all the target platforms
- All repositories have a clear
README.md file describing their purpose and content
Licensing
- The project directory includes a LICENSE file, unless it is proprietary
- The choice of the license is adequately motivated in the report
QA
- The code includes automatic tests
- The code includes unit tests
- The code includes integration tests
- The code includes end-to-end / system tests
- Integration or system tests exploit containerization (if applicable)
- Test code supports parallel runs (runs do not conflict with each other)
- Each test suite can be executed (in principle) even without CI/CD pipelines
- A procedure for the computation of test coverage is in place, and the final coverage is reported and commented
- Static analysis is in place
Final project quality checklist
DevOps
- CI/CD pipelines in place
- CI/CD matrices in place
- The entire test suite is executed in CI/CD
- Automatic release of software artifacts on target repositories (e.g., GitHub releases + artifact repositories for the target platforms)
- If the project accepts contributions from third parties, correct pipeline configuration for pull requests coming from external owners
Domain-driven Design (DDD)
- Domain and bounded contexts have been clearly identified
- Entities, value-objects, and aggregate roots have been adequately modelled according to DDD
- Repositories have been adequately modelled according to DDD
- Services have been adequately modelled according to DDD
- Factories have been adequately modelled according to DDD
- Exploitation of model-integrity patterns is adequately motivated
- The overall design of the system reflects the hexagonal architecture (if applicable)
Final project quality checklist
Requirements
- Requirements are clearly captured and categorized (e.g. functional vs. non-functional)
- Scenarios are clearly described via user stories
- Definition of ‘done’ for each requirement
- The project involves >= 2 target platforms
- The dominant platform cannot be used for more than 75% of the overall project size
- The project is organized in such a way that code targeting different platforms is clearly partitioned
- Core domain entities spanning across multiple platforms are defined so as to minimize code duplication, while enforcing design coherence
AI exploitation
- The report clearly declares what GenAI has been used for and how (or that it was not used at all)
- Each repository has an AI-DECLARATION.md file compliant with the convention (https://ai-declaration.md/)
- Each repository where GenAI was exploited via Agents has an AGENTS.md file compliant with the convention (https://agents.md/)
- Skills possibly exploited by your agents are documented and motivated in the report
Software
Required
- A working internet connection
- A working JDK installation
- Docker
Recommended
- Kotlin
- Gradle
- IntelliJ IDEA
- Visual Studio Code
- A decent Unix terminal
- I recommend a well-configured
zsh shell
- ki-shell (Kotlin Interactive Shell)
Course Container
Feeling lazy?
We prepared a container with all the course’s software:
Follow the instructions at https://github.com/DanySK/docker-linux-didattica
Feeling Windows-y?
The container can be converted into a WSL2 Linux distribution.
(Instructions available in the same repository as above)
Software in lab
The PCs are equipped with the WSL2 image
- There should be a link on the Desktop
- Double-clicking it should pop up a
zsh shell
- Wait for the first terminal to show before starting others