Is it generally acceptable that one repository can access another repository? Specifically in this case, I have one aggregate root that uses another aggregate root to determine what entities to add. It falls along the lines of an Item/Item Type relationship. The reason that the Item Type is an aggregate root is that they are separately maintainable within a management tool outside of the scope of any single Item.
If it does matter, I am only creating my repository instances through a repository factory implementation, so I am not directly creating it by the concrete class name. At no time is the aggregate aware of the repository.
Edit - More information:
The specific implementation is that we can attach images to a document. Not only can we manage the images on the document, but there are different types of images (types being defined as how it is implemented, as opposed to an extension, for example). The document aggregate is one of a few types of other objects in the system that use these images and they do not all use the same types. While we do attach rules in the domain services, this is more specifically geared towards building the document aggregate. When building the aggregate we have five images of a specific type, and one each of two other types. We pull these individually because they are stored in separate lists in the aggregate. The validation is not the issue, but limiting what type of images are being evaluated when assembling the document.
I guess it boils down to what your trying to do. If it's a sort of validation step (e.g. remove all items that have item types that have expired) you could argue it belongs in a service layer or specification. From the language you use (i.e. "determine what entities to add") it seems to suggest the latter, though it's hard to say without more details.
I guess from a certain point of view there's no real reason why you can't (I'm by no means a super DDD purest), especially since an Item and its type could be viewed as an aggregate root and it's only the implementation detail that you need to provide a management console that's prevent.
From another point of view it does seem to suggest that there's a blurring between your aggregate roots that could suggest two different contexts are at work. For instance, one could argue that a management tool forms a separate bounded context to your main application and therefore the case for the Item type being an aggregate root does not really apply. e.g. The management tool might only ever be concerned with Item Types (and never items) while your main application might view item types as more of a value object than an entity.
Update
As you mention assembling the document this seems like the responsibility of a factory class that can correctly assemble a valid entity (the factory can use the image type repository). A repository should (in my eyes) expose querying and adding operations, not the logic to configure entities (except maybe rehydrating from persistence).
It does not follow the principles of DDD to have one repository using another repository. If you need data from one aggregate root to perform some action on another aggregate root, you can retrieve the first root (in the application service layer or possibly in a domain service) and then pass that data into the public api of the dependent aggregate root, or in the case of aggregate root creation where a separate factory is being used, into the factory's public api.
An aggregate root defines a transactional boundary, where the data within it should remain transactionally consistent. This expectation of transactional consistency should not extend to anything outside that boundary. If you have a repository dependent on another respository then you have the state of one aggregate being transactionally dependent on the state another aggregate, which means neither of these 'aggregate roots' are actually aggregate roots.
Furthermore, if you need changes to state of one aggregate to effect the state of another aggregate, you should use domain events for this, which enforce eventual consistency between the roots.
Related
Here is the context of my question. It is typical that one organizes configuration values into different files. In my case, my criteria is easy editing and portability from one server to another. The package is for Internet payments and it is designed so that a single installation of the package can be used for different applications. Also, we expect that an application can have different stages (development, testing, staging and production) on different servers. I use different files for each of the following three categories: the config values that depend only on the application, those that depend only on the server and those that depend on both. In this way, I can easily move the configuration values that depend only on the application from one server to another, say from development to production. They are edited often. So, it is worth it. Similarly, I can edit the values that are specific to the server in a single file without having to maintain redundant copies for the different applications. The term "configuration value" includes anything that must be defined differently in different applications or servers, even functions. If the definition of a function depends on the application or on the server, then it is a part of the configuration process. The term "configuration value" appeared natural to me, even it includes functions.
Now, here is the question. I wanted the functions to be PHPUnit testable. I use PHP, but perhaps the question makes sense in other languages as well. I decided to store the configuration values as properties and methods in classes and used class hierarchy to organize the different categories. The base class is PaymentConfigServer (depend only on the server). The application dependent values are in PaymentConfigApp extends PaymentConfigServer and those that depend on both are in PaymentConfig extends PaymentConfigApp. The class PaymentConfigApp contains configuration values that depend either on the application or on the server, but the file itself contains values that depend on the application only. Similarly, PaymentConfig contains all conf values, but the file itself contains values that depend on both only. Can this use of class hierarchy lead to issues? I am not looking for discussions about the best approach. I just want to know, if you met a similar situation, what issues I should keep in mind, what conflicts could arise, etc?
Typically, subclasses are used to add or modify functionality rather than remove functionality. Thus, the single-inheritance approach you suggested suffers from a conceptual problem that is likely to result in confusion for anyone who has to maintain the application if/when you get hit by a bus: the base class provides support for server-specific configuration, but then you (pretend to) remove that functionality in the PaymentConfigApp subclass, and (pretend to) re-add the functionality in its PaymentConfig subclass.
I am not familiar with the PHP language, but if it supports multiple inheritance, then I think it would be more logical to have two base classes: PaymentConfigServer and PaymentConfigApp, and then have PaymentConfig inherit from both of those base classes.
Another approach might be to have just a single class in which the constructor takes an enum parameter (or a pair of boolean parameters) that is used to specify whether the class should deal with just server-specific configuration, just application-specific configuration, or both types of configuration.
By the way, the approach you are suggesting for maintaining configuration data is not one that I have used. If you are interested in reading about an alternative approach, then you can read an answer I gave to another question on StackOverflow.
I am working on a project with Xpages.I wanted to know how to make the representation of a class diagram to my project.Notes is a documentary database so no relationnal.How I could represent my entities?
In Domino, documents are merely evidence of the existence of people, processes, and physical entities (products, offices, inventory, etc.). Ideally, your classes should model those things.
For instance, you might have classes like Employee, with properties like firstName, lastName, hireDate; maybe Asset, with properties like category, model, serialNumber; or perhaps Request, with properties like status, requester, dateApproved. Eventually the values of each of these properties might be stored as item values in Domino documents, but defining these first as attributes of classes allows you to follow a simple pattern to develop your application:
Use your class structure to rapidly define the nature of each "thing" your application interacts with, without worrying yet what each must look like or how and where the data will ultimately be stored.
Once you have these classes defined, you can bind visual components on an XPage (such as input fields like edit boxes and radio button groups) very easily using the #{dataSource.propertyName} syntax.
When these two steps are done, all you have left to do is to add two methods to each of these entity classes: one to write the data, and another to retrieve it.
Following this approach makes it very easy to rapidly build the application, but also protects your user interface from changes in how you wish the data to be stored. Initially, each object might represent a single document. As the application grows in either complexity or adoption, however, you may decide to segregate the data such that many documents are created to represent a single entity. Or at some point you might even decide to store some, or all, of the data outside of Domino (DB2, SQL, etc.). If your XPage components are bound to properties of these entity classes, all you need to do to change how or where the data is stored is to update the two methods you created in step 3 of the above list: alter how you write and retrieve the data. Your actual XPage design elements don't need to change at all.
Depends how you look at it. You can always think of following relation: Notes Form <-> Java POJO and Notes View <-> Java Collections.
See http://www.pipalia.co.uk/notes-development/rethinking-xpages-part-two/ for some tips on using Java world standards when working with xPages.
I am currently refactoring a project where so far a lot of data was kept as constants and arrays in the code. Also there are a lot of redundancies. Now I want to move all that data into the db, but I am not sure how I would do the mapping. The data is rarely dynamically selected based on user input but rather specifically selected in the code. It is used at a very core level of the application, but it is actually not THE core. Also a database is already being used, so there would be no real extra effort.
My idea would be to use a Mapping class in which I have constants pointing to the IDs of the respective rows. Is that a good idea?
Another idea would be to index the name row and just directly query for the names.
The database would probably have the following columns: id, name, polynom and params.
So, basically we are talking math data. For example: 1, "Price approximation", 20x^3 - 5x^2 + 11x", "non-cumulated".
I think this question is language-agnostic but since there might be a language-specific (or even framework-specific) best practice, here is what I use: PHP5 with the Yii Framework.
I don't have much experience with PHP nor Yii, but here is my 2 cents...
If these are constants and collections of constants that technically define your application (application architecture constants), but the end-user shouldn't have control over, I would put them in a configuration file instead of your database, unless you've built a module to easily access and modify them. Whether you implement a mapping class (or a configuration class) to retrieve them is not important, but be consistent in how you retrieve them. If you have too many to manage in a configuration file, then storing them in the database would be appropriate, but make sure you provide an easy way to modify them. To make your source code readable, I'd use descriptors that a human can understand and map those descriptors to the respective row like you mentioned.
If these are user defined constants, then you should definitely provide an interface. But keep the same architecture as the application architecture constants.
In a perfect program/application (or even better--an application framework), nothing is hard coded, and everything is controlled by constants (switches). If you're able to achieve this successfully without the need to maintain your source code, you will win the Nobel Peace Prize.
How can I know that I need a facade Pattern at a point in my application development?
How can I draw the line between Facade Pattern and Template Pattern?
For example: In [this] article, we see that, int placeOrder(int CustomerID, List<BasketItem> Products) has a number of predefined steps in the algorithm. So why don't the author use Template Pattern here?
Facade deals with interface, not implementation. Its purpose is to hide internal complexity behind a single interface that appears simple on the outside. In the example from your question, the facade hides four classes (Order, OrderLine, Address, BasketItem) behind a single method.
Template method deals with implementation. Its purpose is to extract the common algorithm from several ones that differ only in a 'fill in the blanks' way. The template method in the superclass implements the common algorithm and each subclass 'fills in the blanks' in its own specific way.
So why don't the author use Template Pattern here?
It would make sense to make placeOrder a template method if there were several similar versions of the operation. Maybe a few methods like placePhoneOrder, placeInternetOrder, placeManuallyEnteredOrder could be refactored into a single template placeOrder with some subclasses implementing only the {phone,internet,manual}-specific differences.
The facade pattern is appropriate when you have a complex system that you want to expose to clients in a simplified way, or you want to make an external communication layer over an existing system which is incompatible with your system. It is a structural pattern. See here: http://en.wikipedia.org/wiki/Facade_pattern
The template pattern, on the other hand, is a behavioral pattern that will help you when dealing with the inner implementation of a component. See here: http://en.wikipedia.org/wiki/Template_method_pattern
Suppose you have a few services, libraries or whatever. These libraries need interoperation in order to perform some higher level services. Then you may wish to wrap those calls and intialization code that usually go together and offer a bunch of functions to hide those details and make it simple to use those services for specific scenarios. Then it is a good use for facade pattern.
UPDATE: In the article mentioned the PlaceOrder method has one single implementation that works for all orders. Template pattern is meant to prescribe a series of steps that have to be followed but allow subclasses to offer their custom implementation of those fixed steps. For example, if you needed orders for televisions to be processed differently from orders for microwaves you could use the template pattern to redefine some imaginary DispatchParcel method (to send microwave as a simple package but television with extra service to help lift the heavy device to the upper floor). In our case there is no need for reimplementation of ProcessOrder steps so there is no need for template pattern as one single implementation suits all types of orders.
If one has a object which can persist itself across executions (whether to a DB using ORM, using something like Python's shelve module, etc), should validation of that object's attributes be placed within the class representing it, or outside?
Or, rather; should the persistent object be dumb and expect whatever is setting it's values to be benevolent, or should it be smart and validate the data being assigned to it?
I'm not talking about type validation or user input validation, but rather things that affect the persistent object such as links/references to other objects exist, ensuring numbers are unsigned, that dates aren't out of scope, etc.
Validation is a part of the encapsulation- an object is responsible for it's internal state, and validation is part of it's internal state.
It's like asking "should I let an object do a function and set his own variables or should I user getters to get them all, do the work in an external function and then you setters to set them back?"
Of course you should use a library to do most of the validation- you don't want to implement the "check unsigned values" function in every model, so you implement it at one place and let each model use it in his own code as fit.
The object should validate the data input. Otherwise every part of the application which assigns data has to apply the same set of tests, and every part of the application which retrieves the persisted data will need to handle the possibility that some other module hasn't done their checks properly.
Incidentally I don't think this is an object-oriented thang. It applies to any data persistence construct which takes input. Basically, you're talking Design By Contract preconditions.
My policy is that, for a global code to be robust, each object A should check as much as possible, as early as possible. But the "as much as possible" needs explanation:
The internal coherence of each field B in A (type, range in type etc) should be checked by the field type B itself. If it is a primitive field, or a reused class, it is not possible, so the A object should check it.
The coherence of related fields (if that B field is null, then C must also be) is the typical responsibility of object A.
The coherence of a field B with other codes that are external to A is another matter. This is where the "pojo" approach (in Java, but applicable to any language) comes into play.
The POJO approach says that with all the responsibilities/concerns that we have in modern software (persistance & validation are only two of them), domain model end up being messy and hard to understand. The problem is that these domain objects are central to the understanding of the whole application, to communicating with domain experts and so on. Each time you have to read a domain object code, you have to handle the complexity of all these concerns, while you might care of none or one...
So, in the POJO approach, your domain objects must not carry code related to one of these concerns (which usually carries an interface to implement, or a superclass to have).
All concern except the domain one are out of the object (but some simple information can still be provided, in java usually via Annotations, to parameterize generic external code that handle one concern).
Also, the domain objects relate only to other domain objects, not to some framework classes related to one concern (such as validation, or persistence). So the domain model, with all classes, can be put in a separate "package" (project or whatever), without dependencies on technical or concern-related codes. This make it much easier to understand the heart of a complex application, without all that complexity of these secondary aspects.