- Tags:: đź“ťCuratedNotes , Software Architecture
Canonical explanation on đź“– Patterns of Enterprise Application Architecture, where it is considered as one of the possible Data Source Architectural Patterns:
Each Active Record is responsible for saving and loading to the database and also for any domain logic that acts on the data. This may be all the domain logic in the application, or you may find that some domain logic is held in Transaction Scripts (110) (p. 160).
It’s used by Django as explained in Design philosophies | Django documentation | Django:
Include all relevant domain logic. Models should encapsulate every aspect of an “object,” following Martin Fowler’s Active Record design pattern. This is why both the data represented by a model and information about it (its human-readable name, options like default ordering, etc.) are defined in the model class; all the information needed to understand a given model should be stored in the model.
Using Transaction Scripts in Django is quite a controversial topic: đź—ž Against service layers in Django.
In Django, you can either have static methods in the model, or the Manager/Queryset classes:
Because of the close coupling between the Active Record and the database, I more often see static find methods in this pattern. However, there’s no reason that you can’t separate out the find methods into a separate class (p. 161).
You may use Active Record in a Domain Model, but you shouldn’t if you subscribe to the DDD philosophy (which makes sense in complex domains) since:
Active Record is a good choice for domain logic that isn’t too complex, such as creates, reads, updates and deletes (…). Active Record has the primary advantage of simplicity (…) they work well only if the Active Record objects correspond directly to the database schema: an isomorphic schema. If your business logic is complex, you’ll soon want to use your object’s direct relationships, collections, inheritance and so forth. These don’t map easily onto Active record.
In fact, Active Record would be part of a data-driven approach. From Morts Like Us: Active Record and DDD:
You can choose a data-driven approach or a domain-driven approach, but not both.
A Data Source Architectural Patterns that matches DDD would be the Domain Mapper, which is the proposed pattern in Repository pattern (although that mapping is very simple).