In the CRC cards why do we list all the collaborators instead of just dependency.
I mean if class A calls functions of B, why is A mentioned in the B class CRC collaborator section. It would be much better if we simply leave A in B's CRC card, as in A's CRC card B is already mentioned. This way we can figure out dependency also from CRC card, and if you know the function name of B class that A needs, we can mention that also in the A's CRC card. This would help even more by quickly generate the class and sequence diagrams.
What specific functionality is achieved by mentioning B in A collaborators and A in B collaborators?
Because you don't want to be bogged down to the details of how the collaboration will happen. It may be that A calls out to B, but it may also be that A publishes an event on a message bus that B picks up, or it may be that B passes a callback object to A to which A passess its messages. Listing them as collaborators on both sides avoids having to work out actually how they will collaborate.
Related
If an aggregate needs some read-only data that doesn't belong to itself to performs an operation, is there any negative consequence to let the repository query some data from another aggregate to create the aggregate?
In detail:
I have a BC with two aggregates, say A and B. B needs a bit of data from A to perform some operation but won't modify it in any way. The data fits better on A since there are the rules to modify it.
Reading IDDD and PPP of DDD it seems that it is acceptable to pass a transient reference of an aggregate (or sub entity of it) to another one, or pass a read-only view as a value object to the other aggregate.
In my example, B doesn't need the whole A aggregate but only some specific data, so a value object seems like a good approach in this case. A could create the VO acting as a factory, the VO will conform to the UL and B doesn't need to be aware of A at all. A business use case in the application layer can reconstitute A and B from repositories, tell A to create the VO and performs operation on B passing VO.
Lets suppose now that reconstitution of A is expensive or there is another reason for what is not desirable to load the whole A to create the VO with just a bit of information (maybe the data is not from one instance of A but is aggregated from a list of them or whatever). Here a simple solution could be let the repository of A create the VO directly from the data store. I feel comfortable with this and seems it is a common pattern.
But now I'm thinking in a case when the operation on B is performed many times, or maybe is part of a bigger calculation on B that many other operations need. I could have a reference to the VO with the data needed (as a private, read-only property of B or somewhere in its graph) and let the repository of B take the data needed to create the VO and reconstitute B with it. Now B will always have the data locally to performs its operations. The data taken from A cannot be modified; saving B through its repository will just discard that data (maybe it could use it to detect a conflicting concurrent update), A and B will not be consistent at all times but that's OK, and reload B from repository will query the data again to update the view inside B in case of a conflict.
This approach seems OK to me since, as I understand, the domain model is unrelated to the data model, with the repository acting as a sort of ACL between the two. Also there is a single source of truth for the data inside A since the copy inside B is immutable and eventually consistent. The drawbacks I see are that repository will have more logic (but not business logic) and that it could be unclear where exactly the data is coming from since the dependency from B to A is now hidden inside infrastructural code.
So the questions are:
Is this a not-so-good approach after all?
Is there another drawback I am not seeing?
Did you or someone do something like this so I can learn from that experience?
I know the example is very poor since in DDD everything is about context. But this is a question I came up many times in different situations. I know as well that a valid concern is if aggregate boundaries are well defined, but let say they look good for the problem at hand.
is it acceptable to let the repository query some data from another aggregate to create the aggregate?
Acceptable is kind of weakly defined. A better question to ask might be "are there negative consequences?"
In this example, the usual consideration is whether or not the system becomes harder to change. Take a look at Adam Ralph's talk on service boundaries to get a sense for what happens when you don't control the coupling between components.
These days, if B needs a copy of A's data, then we usually introduce into our design of B a cache of A's data. Store the copy of the data with B, and work out explicitly how and when updates to A are communicated to B. The cache becomes part of B's data model.
See also Pat Helland's paper: Data on the Outside versus Data on the Inside..
Recently I have fallen in a situation like this. I'm generalizing the problem because I think it relates more to the structural design than the specific problem.
General problem
There is a hierarchy of classes: an abstract base class Base and some concretions D1, D2, D3 that inherit from it. The class A contains an object's collection of type Base. A requires a computation from some service-class B but B.process() method accepts only a collection of type D1. Let's say that is important because if the input collection contains any other type the value returned is just wrong.
A have an interface that allows clients to add elements to the internal collection, which is not exposed in any other way. The classes in the hierarchy can be constructed for the same clients and pass the new values to A; A have not enough context to construct them itself.
Attempts, questions and thoughts
The major concern for me was the need to determine at runtime the type of each element in the A collection, so can filter the right ones and pass to B.process(). Even if it is possible (it is in my particular problem, more later on) it just seems wrong! I think the object who contains references to the abstract base class shouldn't have to know the concrete instances it holds.
I try to:
Change the parameter type to B.process(c: Base[]) so A doesn't have to downcast the type, but it doesn't solve anything: A still needs to filter the elements or the computation will be wrong.
Pass the complete collection Base[] to B.process() but just defer the problem of selection/downcasting to B.
Put a process() method in Base so D1 can override the behavior (well known polymorphism). The problem here is that a process() returning a SomeValue type just have sense for D1.
Separate the interface that add elements so a more specific A.addD1Element(e: D1) method could allow put D1 objects in a different collection and pass that to B. It should work but also looks... don't know, weird. If method overload based on parameter type is possible at least the process won't be so cumbersome for clients of the class.
Just separate the D1 class of the hierarchy. This is a more aggressive variation of the previous one. The issue is that D1 seems related to the whole hierarchy except for the specific requirements of B.
Those were some of my thoughts on the problem.
For instance, the language used have support to check the type of an object at runtime (instanceof) and it is easy to filter the collection based on that check. But as I say my question is more related to the paradigm. What about a language, say for instance C++, where is less handy to make a check like that?
So what could be a solution to this kind of problem? What kind of refactoring or design pattern could be applied so the problem is easy to treat with or simply fades away?
This question looks related, but I believe this is more general (although I provide a more specific context). The most upvoted answer suggest to split in different collections. This is also a think i'm considering, but that forces to change A implementation every time a new type is added.
Context (problem in action)
I'm asking in a general way because it really intrigues me on that way, but I know most of the time a design can be analyzed only with the context of the particular problem it tries to solve.
The problem at hand is similar to this:
A is a class (some kind of entity, like a DDD entity) that models a sort of agreement or debt a customer incurs for a service. It has different costs including a monthly pay. Base and related classes are Payments of different types. They share a lot in common, although most of it is data (date, amount, interests, etc); but there is at least one type of payment that have different, additional information: the monthly payment (D1). Those payments need to be analyzed carefully so a different class (B) is responsible for that, using more contextual information and all the payments of that type at once. The service needs the additional data that is specific to those payments so cannot receive an abstract Payment type (at least not in that design). Other payments doesn't have the specific information MonthlyPayment does and so they cannot generates the values that business requires and B is generating (doesn't have sense in other payment types).
All payments are stored in the same collection so other methods of the class can process all payments in a generic way.
This is mostly the context. I think the design is not the best, but I fail to see a better one.
Maybe separating only MonthlyPayment (D1) in a different collection as described earlier? But it is not the only payment that requires additional processing (it is the most complex, though), so I could end with different collections for every payment type and no hierarchy at all. Right now there are four payments types and two of them requires additional, specific analysis, but more types can be added later and the issue of need to modify the implementation every time a new type is added persists.
Is this, more discrete approach of different collections by type, a better one here? The abstract base class Payment can still be used for payments that can be manipulated trough the common interface. Also I can use a layer super type or something like that to allow reutilization of common functionality (the language allows a kind of mixing as well) and stop using the base class as root from a hierarchy.
Uf. I am sorry for the length of the text. I hope it is at least readable and clear. Thank you very much in advance.
I'm building an iPhone app that has a central class, M, that gets a bunch of data from a Web API. Whenever this class gets data, it has to update two controllers, say A and B. To support this both A and B are listed under an interface that has an update command. A and B also need to be able to query data from class M, so I've added a handle to M in both A and B.
The problem is that is setup isn't very modular. I'm looking for ways to clean up the design.
EDIT - Also, class M doesn't have any preconceived notion of what the exact type of the class A and B will be.
Thanks.
Just do as you're proposing on the title: use the observer pattern. A and B are observers (that implement an observer protocol) to M, which is the subject. When you update the observers, also provide the event data through the update method, maybe as a handle to a subject protocol that M implements. This way, A and B are decoupled from M through the observer and subject protocols.
Consider the following general program structure:
Class A has an instance of Class B as a member variable
Class B has a collection member variable containing instances of class C
Events in class A are propagated to the C instances by A simply telling B about the event
What are the design patterns concerning instances of class C talking back to class A?
One option is instances of class C posting notifications to which class A subscribes. Another option is passing a reference to class A "down the chain" (from A to B then from B to each C). This latter option allows instances of C to talk directly to A.
If you mean design patterns literally (i.e. of the GoF variety) then these would be a few relevant options:
Command: pass a callback to the C items (directly or indirectly through B) so that when they want to talk back to A they can simply invoke this callback -- which can even have parameters
Iterator: B exposes a view of its aggregate collection directly to A; communication between A and C is then made directly
Mediator: Exposes notifications to which A and C might subscribe to; communication is done by posting events
Observer: What you already suggested as the first option
If on the other hand you really mean architectural patterns, then typical options are:
Your first option, A subscribing to C events. At first sight this doesn't look like an all-around good idea unless the event is extremely useful all the time, because it requires n objects to aggregate a pointer back to the callback which in the worst case they could even use just once.
Passing references to A is another option, but not a good one if you are going to pollute the public interface of A with methods just so that C can call back to it in very specific scenarios. It can be very effective if A already exposes a suitable interface, but be aware that you might need an adapter class between C calling back to A in order to not tightly couple C to A's interface.
A third option would be A iterating over (a view of) the collection provided by B directly and supplying callbacks to C instances; this has the advantages of being quite loosely coupled and that it will use the least amount of memory, but it might be a bit trickier to code.
I have two components, A and B.
Component B requires that A has a certain state.
I can write this as part of B's code,
or I can write this as part of A's code (and maybe add assertions to B)
What should I take into consideration when making such a decision?
Edit
In this scenario there might be several B-type components.
It's also assumed that I can't avoid this situation
Edit 2
This often happens when working with frameworks. I usually have a some sort of "global settings", and components that require those settings to be something
Possibilities:
Have A implement an interface that will B will check
Make A create B whenever it has such a state.
Generally, the first solution is used, because ALL Bs refer to A, but A doesn't actually have to know about ALL Bs (you said there were many). In theory, every object should do what it is supposed to do, ignoring anything else exists, unless its a controller object.
With the first solution, B checks what A has.
With the second solution, A becomes the controller of all Bs.
I would say that it's better to have Bs check for A on creation, but in special cases, like when A is your main controller class, it MIGHT be preferable to have A create B.
Edit as response to Edit 2 by OP
Yes, in this case it's almost always better to have B check in global settings. Global settings are there so you can check them! The only exception is if A is also the owner of all other components (such as the Game class in XNA)... Even there it would be difficult to choose and just to keep the architecture intact I'd still make B check inside of A, it's just more clean and healthy.
I'm not sure that coupling is too high (at least not from your description of the problem alone).
I think the general answer to your general question comes from the concept of ownership/responsibility that so pervades OO in general. If B needs A to be in some state before doing something, then B must make sure A is in that state before doing it. Responsibility lies with B - put the code in B.
Presumably A has its own life independent of B. Let it be A, man.