I have a model e.g. Book. Besides ‘natural’ attributes of a book, I have some mandatory IDs I need to carry on, like companyId, groupId. They are related to which organization unit this book belongs to.
Now, I see these two flags like something that is not part of the Book interface. Since all the work with a book is done in the context of one organization unit. In other words, organization unit is always known for every operation out there. Yet, we need to store these data to database and have them in the model (for other modules as well).
[A] Should I put these attributes part of the Book? Then they become mandatory flags and must be set in the constructor of the Book. Meaning, I need to set them every time i create a book. Which somehow I don’t like, as these fields belong to the organizational units, which Book should not know anything about.
[B] Should I put these attributes in some ‘thread local context? ThenBook` can not be used without the thread local, and this technical dependency is not visible from the outside.
[C] I can store them in the Book fields, but not expose it to the Book interface. However, when I send Book to some other module, that module must be aware of these IDs. Should I use reflection – but then, I must be sure that fields are named the same.
So I wonder if it is possible somehow to have these fields with the Book but not to become part of the Book interface.
1
Introductory texts about object oriented design always focus on these “natural” objects that are modeled by code. This, I think, is usually a mistake, and results in a lot of confusion when trying to implement an architecture, since you’re trying to model the wrong thing.
An object oriented architecture deals with types and classes in your solution’s problem domain. If you’re building a book-tracking application, you might not really interested in many “natural” qualities of a book, like the typeface it’s printed in or the condition of its spine, but rather in those qualities that are relevant to your application – its name and author, certainly, but perhaps also its owner and current location, both relevant to the entity Book in your domain context, even if not part of some platonic ideal of a book.
So I say, go ahead and add properties like CompanyId to your Book model, if that’s the relevant entity you’re trying to model. If that seems jarring, stop calling it a Book – call it a ManagedBook or a TrackedBook, and suddenly you see that those properties do make sense.
You said it yourself, there is some kind of context, in which every book is handled. This OrganizationContext might be a class. And every time you load or save a book, this class knows about it and can do it’s own logic on those field. Also, to make the coupling looser you could have HasOrganizationContext interface to represent those IDs and allow for different entities to belong to this context and not just Books. Then, other modules could know about this context, but don’t need to know about book itself.
Also, if you use C#, you could use explicit interface implementation to “hide” the fields from view, while still making them visible to those who know about the interface.