Class Diagrams

UML, Code Map & Domain Models

Creating class diagrams is especially fun when you work with many different domains and boundary contexts. Our challenge was to come up with loosely coupled data classes that don’t cross each others’ boundary context.

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD’s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

https://martinfowler.com/bliki/BoundedContext.html

In the end, we came up with something like this. This is a rough estimate of all of our domain data models and subject to change until we figure out which domains are going to make use of what kind of database framework (NoSQL or relational, that’s the question. Most likely NoSQL for most domains).

You may notice that we don’t really reference other object types and kinda neglect the object-oriented paradigm. Unfortunately, as much as I love OOP, it’s simply not possible when you attempt to develop large-scale microservices with their own domain models. Domain Driven Development make sense in our case. So for instance, instead of referring Users by their object reference, we are required to store their IDs in the databases (that should be obvious enough though). Each boundary context has its own database.

In addition to the class diagram generated by Visual Studio, VS also has the capability to generate beautiful Code Maps. This helps to visualize the individual domains and boundary contexts. Have a look:

That should be all for this week. We also changed our SRS this week and sadly, the backend projects need some adjustments and part of it a small rewrite to cope with the new requirements. Scroll down to read more.

Cheers, see you next week,
Gino

Application Roles

This section was written by team member Robin who is going to provide an update to available roles available for Foody.

Last week we discussed where and how to deploy our Foody page in the future. We decided to concentrate on DHBW in the first place but we want to provide the service to other universities or schools in the (more less far) future.

As we discussed, we talked about role systems that shall simplify the deployment and implementation for external use and had a small dispute about which roles shall be implemented and who shall be provided with them.

To evaluate the problem we started from the beginning with writing down which permissions shall be provided at all. This is our result:

• User Management:
  create a course, invite users, manage the roles of users, delete users/courses.
• Course Time Table:
  create a local timeline from iCal by course, create local events, change/delete local events
• Bet Management:
  create a bet, create option, vote, set amount, delete bets

As you can see we’ve just focussed on tasks without any context so far. This will be evaluated when it comes to implementation soon. In the next step, we decided on which roles we want to implement those tasks (with some specifications). The result is as follows:

• Client/User:
  create a bet, create option, vote, set amount
• Local/Course Admin:
  invite users, manage roles of users, create a local timeline by iCal by course, create local events, change/delete local events, create iCal from local calendar, delete bets
• Global Admin:
  create course, delete users/courses

The power of admin-roles rises from top to bottom. All possibilities given to the former/lower-prioritized role are also given to the higher-rated ones.

Now we have to evaluate how we want to implement this into our data structure. Be curious, this will be a blast.

That’s it for now, have a good one.
Cheers. -RM-