0

I'm working on a personal project manipulating list of bets and odds in sport games. So I've got a sport->event->match->bet->odd hierarchy to handle.

I'm trying to do it, also as an exercise as I'm quite new to those concepts, in respect of the rules described in Teresko's answer in his great post here under :

How should a model be structured in MVC? (To sum up, his answers explains that the model layer of an MVC app is usually made of Domain objects, data mappers and services)

One of the functionalities that I'll need is to generate a list of the matches of the day, showing as well some datas of the sports and events they're attached to as well as bets and odds attached to them.

And I can't figure out yet how to correctly design that hierarchy. My current idea is to assume that sports, events, matchs, etc aka the nodes of my hierarchy tree are all domain objects and will have their associated data mapper. My hierarchy, would be a Domain Object as well, that would handle infos about the tree structure, and have it's own dataMapper. That dataMapper would realize transversal fetching jobs like returning the matches of the day. That would in the end be a big join on the different tables and attributes that the 5 different nodes data mappers (one for sport, one for event, etc) would provide him.

I really feel like I'm missing something here and that this is not the way to go. But that kind of organization sounds quite common so I was hoping that you guys may know about some usual and elegant way of handling this.

thanks in advance,

Wish you all a pleasant day.

Community
  • 1
  • 1
Hector
  • 101
  • 1
  • 4
  • @Hector Could you add a bit of code that illustrates what you currently have? From your description only it's kind of difficult to figure out where you're stuck exactly. – theDmi Nov 10 '15 at 12:46
  • @theDmi I know that very well, but I rarely seen a case where it's worth querying through the domain model anyway. Doing so encourages you to create aggregate roots that do not clearly express their boundaries (e.g. referencing an AR2 from an AR1 to simplify data access rather than simply referencing AR2 by id). When you only focus on commands that's where DDD shines, because DDD is mostly about behaviors. Focusing on behaviors will naturally lead to adequate compositions rather than artificial and unecessary compositions. – plalx Nov 10 '15 at 12:57
  • @plalx Cross referencing aggregates is bad in DDD. Regardless of whether you use CQRS or not. But suggesting to use CQRS (which your first comment implicitly does) is just not constructive here, that's all I wanted to say with my comment. – theDmi Nov 10 '15 at 13:03
  • @theDmi My point was more that I'm sure if the OP wasn't thinking about queries he would automatically recognize that an aggregation like `sport->event->match->bet->odd` probably makes no sense and is much too huge as a transactionnal boundary. Instead if he was focused on what are `Event`, `Match`, `Bet`, etc. what behaviors are attached to those concepts and what data is needed to fulfill those behaviors he probably wouldn't be asking this question. Using CQRS forces you to do that automatically because there's no queries in the domain so what else can you focus on instead of commands? – plalx Nov 10 '15 at 13:14
  • @theDmi I agree that my comment wasn't clear however and I'll remove it. – plalx Nov 10 '15 at 13:17

1 Answers1

0

As you have used the DDD tag, it would be helpful for you to consider one of DDD's fundamental concepts; the bounded context.

It sounds like your application has a number of them; fixtures (what games are taking place, where and when), betting (odds, bets) and so forth. Your question suggests that you are trying to come up with a single, unified model to cater for all these concerns which is the exact opposite of what DDD entails. You will drown in complexity if you engineer this using a monolithic model.

Try to identify the boundaries between all the responsibilities of your problem in terms of the domain language, not in terms of the infrastructure.

Matt
  • 1,648
  • 12
  • 22