Yes, and you should. Note the "domain objects" cited from the book doesn't mean "model objects". In an active record model (as in Django) it can be a bit confusing, but you should have the so called Business Objects. It is what the book calls "domain objects". They are objects that map the "problem domain".
They are not models, as the Active Record lead us to think of. They are classes that "see the big picture". They use model classes and eventually other Business Objects classes, too. So, this arrangement to guarantee integrity should lay not in model classes. Basically, the Active Record pattern maps one instance of the object to a table row and it has some drawbacks. For instance, an order without items is not an order at all. So, how to solve it using Active Record? You don't. The pattern is not well suited for this case. To make this in a proper way, you should create an object Order (not a model instance!), other object OrderItem and assure your rules go through Order. It's a basic entity relationship, with a strong and a weak entity. An OrderItem doesn't exist without an Order. So, you need an structure to represent a "full order" that don't map directly to a table row. You should separate this in domain model objects. Yes, it looks like Java. But actually, it's design pattern. I recommend you the talk "Architecture: The Lost Years", from Uncle Bob: https://www.youtube.com/watch?v=HhNIttd87xs This article (http://blog.codefx.org/design/architecture/architecture-lost-years/) makes some analysis on the talk. -- Vinicius Assef. On Wednesday, 11 November 2015 20:46:15 UTC-2, Alex Newman wrote: > > I almost hate to bring this up, but we are reading Eric Evan's book > "Domain Driven Development" at my company in our technical bookclub and > some techniques in the book seem to be hard to apply in DJango. The main > one being the notion of aggregations: > > From http://martinfowler.com/bliki/DDD_Aggregate.html > "Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a > cluster of domain objects that can be treated as a single unit. An example > may be an order and its line-items, these will be separate objects, but > it's useful to treat the order (together with its line items) as a single > aggregate. > > An aggregate will have one of its component objects be the aggregate root. > Any references from outside the aggregate should only go to the aggregate > root. The root can thus ensure the integrity of the aggregate as a whole." > > Can we actually enforce this in django? > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e3526a83-fbc4-4746-a389-4cc8426e7565%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
