Looking for some direction

Imported from Google Groups
#1

Greetings,
I am currently evaluating Axon to see if it’s a good fit for migrating a monolithic application to a microservice architecture. I’ve looked at a few examples, but they seem a little too simple for me to answer the questions I have. I’m basically just looking for a little direction here, so I will try to keep it simple.

  • App is named subscription-service
  • Billing Plan has
  • a set of Features that specify the other services to which the user/subscriber has access
  • a base price
  • a price per facility- Feature
  • Fairly simple object. Might be an enum. I envision this as a value in a multi-select box when creating/updating a plan.- Subscription has
  • start/expiration dates
  • associated Billing Plan

  • facilities- Subscriber has

  • one or more subscriptions (or Subscription could have an associated Subscriber)
    How might I go about modeling this? Not necessarily looking for code (although it is welcome). Just some sort of narrative.

Thanks.

#2

Hi Brian,

first, a disclaimer and a warning, modelling is a very delicate operation, because everything depends on a lot of factors, which are completely lost over email. So any answers given here are most likely to be wrong, but the approach taken is reusable to obtain a “correct” answer.

It sounds like you would have 3 aggregates in your application: BillingPlan, Subscription and Subscriber. Although BillingPlan maybe doesn’t need to be its own aggregate, but could be a member in the Subscription aggregate. Main question here would be what their lifecycle looks like. Is a biling plan some sort of “master configuration” that subscriptions use, or will each subscription have its own billing plan, independent of any other subscriptions?

Depending on the views that you have, you would model views that contain the data required for those views. You could very well have slightly different boundaries there.

Note that the aggregates in your command model should not be defined by what they “have” (i.e. data/fields), but by what they “do” (i.e. activity/commands/events).

I hope these guidelines help.

Also, be aware that AxonIQ can support you both int he development phase, as well as the design phase. Don’t hesitate to send me a private message if we can help.

Cheers,

Allard