0

Where do you draw the line for how much logic can go in your read models? For example, we have 2 BCs: Inventory and Sales. We need to generate reports regarding inventory levels on specific dates: perfect for a Read Model.

Simple SELECT from InventoryItem and OrderLine tables based on the ProductSKU. I can then use the current state of the InventoryItem to compute what inventory would be on a date using the date when orders were placed.

However, there seems to be a lot of logic in this ReadModel class to do this. Also, what if I want to change what gets reported based on an Order status (e.g. PENDING vs SHIPPED)? Doesn't this force even more business logic into the ReadModel?

TL;DR: where do you draw the line with calculation logic on ReadModels?

Improve this question

1 Answer 1

Reset to default
1

This comes down to how you define "business logic". This phrase is usually used in reference to business processes that alter data or mediate flow (which usually ends by altering data).

IMO simply offering different projections of data isn't really business logic. It's presentation logic. Sometimes presentation logic can get complex as well. I understand that generated reports can lead/allow stakeholders to make business decisions, but unless you are attempting to automate this decision-making process, I see no reason to complicate your domain.

For example, unless you want your Product.IncreasePrice method to have an invariant mandating that it must have been ordered X number of times between two dates, you are only cluttering your domain model.

Improve this answer
3
  • As always great answer; however, what about being able to query for a report? Somewhere you would need to keep a list of transactions that have no effect on the business logic. For example, an inventory system.. You want to see stock levels over time (not business logic as you alluded to); however, I need to track where purchases, sells, and stock adjustments happen. So you're saying to keep this out of the domain model? Also, you're duplicating data because if you keep a stored integer of StockAvailable and then have the transactions as well, you might have data that gets out of sync.
    – keelerjr12
    Commented Nov 27, 2018 at 22:08
  • Another example would be banking Accounts that don't store the current balance but keep a list of transactions that are then used to compute the balance. Is this list of transactions considered domain logic or reporting?
    – keelerjr12
    Commented Nov 27, 2018 at 22:10
  • @keelerjr12 I think it may be useful to treat/understand reporting as a read model. In this way duplication/denormalization is to be expected. Of course, eventual consistency may also be a necessary trade off. In regard to your Account example, the data can be both. The Domain is responsible for mediating how new transactions enter the system or how they change, and Reporting can read the data for whatever purpose is necessary. The focus of DDD is on the behavior of a system. Read models can be generated freely ad-hoc.
    – user3347715
    Commented Nov 28, 2018 at 5:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.