CODEWITHSUNDEEP
javamongodbspring-bootarchitecturedomain-driven-design
Viswa
Viswa

Reputation: 3211

How to architecture dynamic domain model java web app

Domain model are

Event (Fun, Sports, Quiz ) has many Problems (Fun problems, Sports, Quiz related problems).

Problem has many solutions (each team uploads a solution), solution has many grade (each Judge posts grade).

Initial goal is to start with one type of event (for example Quiz event) and it has multiple problems and solutions. Judge can grade the solutions.

In future there may be new type of event (Spots event) can come in with different properties & behaviours. For the sports event, problem may have new set of properties & behaviours and solution module should be disabled because for sports event judge can directly update grade.

So do i need to have workflow for each event, to turn on & off a particular module.

want to do as micro services with spring boot with mongodb.

What i done so far

I have

abstract class for Event, Problem, Solution and grade (Based on the event type grading property may change).

Registration domain with Team, Problem and solution as reference property.

How to proceed further and am i do it current ?

Upvotes: 0

Views: 531

Answers (1)

Rubasace
Rubasace

Reputation: 969

I think you can start by modeling an scalable design. In my opinion the starting point is correct as you have to distinguish between Events, Problems, Solutions, Teams and Judges.

Once this is done, I always try to make things as much generic as I can, so when I start to mix all the pieces they can interact independently of their real state. This is, I try to make the interaction between the pieces just by using their interfaces / abstract classes (One problem -> Many Solutions, One Team -> One Solution, etc). I see no information about those properties you talk about, but I suposse they can belong to the generic Problem and just be configured on each specific type of Problem (but not declared).

If you are able to achieve this, you can then create an enumeration for the types (Fun, Sports, Quiz, Spots) so you can configure each type of problem by the relationship Problem-Type.

I don't know how to represent the Problems as I have not enough information on your domain. But what I would do is something like this, so when new types of problems appear in the future I only have to create a new type enumeration value and its relationships:

quick design

Undertand it just as an example for making easier for you to understand my words, it's quite far from what the real design would be as I have not enough information about each piece on the puzzle.

Even though, with that as an starting point you can choose to apply some interesting design patterns such as Abstract Factory (if you want to supply the solution as a template for a given problem, so teams have to fill it instead of creating it from scratch) or Strategy Pattern (so you can interact the same way with each Problem and let the behaviour be controlled depending on the ProblemType or any other variable that determines the Problem state).

As a summary:

  1. Try to extract the common factor of each part and how it itneracts with other ones.
  2. Additionally, try to make interaction independently of particular types and properties, exposing as much as you can in the common interfaces (as long as it makes sense, obviously).
  3. If not possible, Abstract Factory is an option, so it lets you make internal relationships aware of implementation details without coupling the external parts.

Once you do that you will be one step closer to making a dynamic model that grows with no efforts meeting your needs.

Upvotes: 1

Related Questions