New answers tagged

0

How small could be an aggregate? An AGGREGATE can be as small as one domain ENTITY. Entities, values, and "domain services" are the patterns that normally appear when we are modeling the domain. Properties like Color are normally implemented using Values - the fact that you are thinking that color has "no business logic" is a Big Hint[...


1

First and foremost, the main idea of having a domain model is to wrap your business logic. Second, an aggregate is a set of business-related entities (order and orderline can form an aggregate), each aggregate should have a root, which is logically the one entity that forms transactional consistency boundary, so for example if you delete it you'd delete all ...


0

I would separate the date range into a separate table and use a foreign key to link each price to it: Item(item_code, (...) ) ItemPrice(item_price_id, item_code, price_date_range_id) PriceDateRange(item_date_id, start_date, end_date) Using this may complicate the SQL a little, but have other benefits: You can adjust each price range however you like, and ...


3

I don't really understand why the second involves fewer rows. Here's what I would do: Use the first schema but interpret your date as the date from which the price was effective. Then when you want a price for a given date you just pick the earliest one that was >= the date you're interested it. You get a unique constraint (good), minimal storage(good) ...


Top 50 recent answers are included