Domain-driven design suggest that we should create an aggregate root by using a factory to hide the complexity. We can use the following ways to create the aggregate root:
Static factory method in a factory class
Aggregate root that has a factory method
On What basis do we make a selection between (1) and (2)?
Consider having a factory method on the on the AR when the resulting code aligns better with your ubiquitous language and when the AR has some knowledge that will simplify the creation process.
For instance, if in your domain you can add tasks to a project and tasks are modeled as ARs then Task task = project.addTask(taskId, taskName); is more expressive and simple than Task task = new Task(taskId, taskName, projectId);.
Factories are not exactly specific to DDD. You can find the Factory pattern in GoF, for example.
Usually, you make your choice based on the following:
If your factory returns different types, depending on the arguments, it should be placed in a class
If your factory always returns an instance of one class, it should be made as a static method inside this class
When it comes to DDD, you normally would have factory methods on your aggregate roots anyway, to encapsulate the complex creation logic, if you have such logic of course. Factories are named according your Ubiquitous Language and ensure that only consistent aggregates can be created.
Your first suggestion
Static factory method in a factory class
is something you should generally avoid. Public static methods are a code smell if they have service character (which factories do). It's better to create a non-static class, inject it wherever it is used and call the instance method on it. Create an interface if necessary. This approach improves testability and makes dependencies between classes explicit.
If you follow this advice, your question becomes a question of factory method pattern vs abstract factory pattern.
Factory Method
Use factory methods when there are multiple ways to construct an object of a certain class. Factory methods are preferable to direct constructor calls in this case because you can give them a descriptive name. If you use them, it usually makes sense to make the constructor private, so that clients realize that they should not call the constructor, but call the appropriate factory method.
Factory methods just wrap the constructor. As a consequence, they cannot really simplify the construction of an object (apart from giving it a name).
Abstract Factory
If constructing an object is non-trivial, the pattern of choice is the abstract factory pattern. Note that you are not required to have multiple classes to be able to use an abstract factory as suggested by Alexey Zimarev. An abstract factory makes perfect sense with just one type of object that is being created.
Abstract factories are a special kind of a service, namely a service that creates objects. As such, they can have dependencies, which they can provide to the created objects for example.
Example: Let's say you want to create an object that needs a string value and a dependency to ISomeService. Here, an abstract factory can help by providing ISomeService. The interface of the factory would then look like this:
interface IFooFactory {
IBar CreateBar(string value);
}
This factory simplifies creation of an IBar for clients, because they don't have to provide the ISomeService themselves.
In the context of DDD Aggregates
Aggregates often contain references to domain services. As such, instantiation of aggregates is often non-trivial, so the abstract factory pattern is a good fit here.
They are basically the same. Option 1. might help you avoid having a bloated entity class. Option 2. is better if the creation reads more naturally when prefixing by the name of the entity, as in
LoyaltyCard.ForCustomer(...)
SavedSearch.WithCriteria(...)
Related
Assuming that I want that following Value Object contains always capitalized String value. Is it eligible to do it like this with toUpperCase() in constructor?
class CapitalizedId(value: String) {
val value: String = value.toUpperCase()
// getters
// equals and hashCode
}
In general, I do not see a problem of performing such a simple transformation in a value object's constructor. There should of course be no surprises for the user of a constructor but as the name CapitalizedId already tells you that whatever will be created will be capitalized there is no surprise, from my point of view. I also perform validity checks in constructors to ensure business invariants are adhered.
If you are worried to not perform operations in a constructor or if the operations and validations become too complex you can always provide factory methods instead (or in Kotlin using companion, I guess, not a Kotlin expert) containing all the heavy lifting (think of LocalDateTime.of()) and validation logic and use it somehow like this:
CapitalizedId.of("abc5464g");
Note: when implementing a factory method the constructor should be made private in such cases
Is it eligible to do it like this with toUpperCase() in constructor?
Yes, in the sense that what you end up with is still an expression of the ValueObject pattern.
It's not consistent with the idea that initializers should initialize, and not also include other responsibilities. See Misko Hevery 2008.
Will this specific implementation be an expensive mistake? Probably not
I was wondering whether it would be considered bad practice to use an aggregate identifier across a service in another (extensipn) aggregate which shares that they are both revolving about the same identifiable entity.
The problem I am currently having is that we want to split some logic (bounded context if you so will) into a different service as the one originally creating the aggregate.
In general, this seems to work, as when I send a Command within the second service, it is picked up and updates its state. As I can use EventSourcingHandler to also use Events created in the other service to manipulate its state, I get state information from a source applied by the first services aggregate.
I was worried that the snapshot mechanism would work against me, but apparently it is smart enough to store snapshots separately as long as I make sure the aggregate "type" name is not the same.
So far, so good, the only thing that's a smell for me is that the second aggregate does not have (needs) an initial constructor CommandHandler, as the creation is done in the first aggregate.
So, am I going against the way axon framework intends aggregates to be used, or is this a viable use case?
#Aggregate
#Getter
#NoArgsConstructor
public class Foo {
#AggregateIdentifier
private String fooIdentifier;
#CommandHandler
public Foo(CreateFooCommand command) {
apply(FooCreatedEvent.builder()
.fooIdentifier(command.getFooIdentifier())
.build());
}
#EventSourcingHandler
public void on(FooCreatedEvent event) {
this.fooIdentifier = event.getFooIdentifier();
}
}
#Aggregate
#Getter
#NoArgsConstructor
public class Bar {
#AggregateIdentifier
private String fooIdentifier;
private String barProperty;
#CommandHandler
public void on(UpdateBarCommand command) {
apply(BarUpdatedEvent.builder()
.fooIdentifier(this.fooIdentifier)
.barProperty(command.getBarProperty())
.build());
}
#EventSourcingHandler
public void on(FooCreatedEvent event) {
this.fooIdentifier = event.getFooIdentifier();
}
#EventSourcingHandler
public void on(BarUpdatedEvent event) {
this.barProperty = event.getBarProperty();
}
}
The case for why I tried to split is that we wanted to separate the base logic (creation of the aggregate, in this case a vehicle) from the logic that happens and is handled in a different bounded context and separate microservice (transfers from and to a construction site). Since I cannot publish a creation event (CommandHandler in the constructor, sequence 0) for the same aggregate identifier but different aggregate type twice, I could not separate the two states completely.
So my only options right now would be what I presented above, or use the creation of the second aggregate to set a different aggregateId, but also add internally the aggregateId of the first aggregate to allow for events to be published with the aggregateId information of the first as a reference Id. To make this work I would have to keep a projection to map back and forth between the two identifiers, which also does not look too good.
Thanks in advance,
Lars Karschen
Very interesting solution you've come up with Lars. Cannot say I have ever split the Aggregate logic in such a manor that one service creates it and another loads the same events to recreate that state in it's own form.
So, am I going against the way axon framework intends aggregates to be used, or is this a viable use case?
To be honest, I don't think this would be the intended usage. Not so much because of Axon, but more because of the term Bounded Context you are using. Between contexts, you should share very consciously, as terms (the ubiquitous language) differs per context. Your events are essentially part of that languages, so sharing the entirety of an aggregate's stream with another service would not be something I'd suggest normally.
Whether these services you are talking about truly belong to distinct Bounded Contexts is not something I can deduce right now, as I am not your domain expert. If they do belong to the same context, sharing the events is perfectly fine. Then still I wouldn't recreate a different aggregate based on the same events. So, let me add another concept which might help.
What I take from your description, is that you have something called a Vehicle aggregate which transitions different states. Wouldn't a Polymorphic Aggregate be the solution you are looking for? That way you can have a parent Vehicle aggregate with all the basics, and more specific implementations when necessary? Still, this might not fit your solution completely, something I am uncertain about given your description.
So, I am going to add a third pointer which I think is valuable to highlight:
Since I cannot publish a creation event (CommandHandler in the constructor, sequence 0) for the same aggregate identifier but different aggregate type twice, I could not separate the two states completely.
This line suggests you want to reuse the Aggregate Identifier between different Aggregates, something which comes back in the question's title too. As you've noted, [aggregate identifier , sequence number] pairs need to be unique. Hence, reusing an aggregate identifier for a different type of aggregate is not an option. Know however that Axon will use the toString method of your aggregate identifier class to fill in the aggregate identifier field. If you would thus adjust the toString() method to include the aggregate type, you'd be able to keep the uniqueness requirement and still reuse your aggregate identifier.
For example, the toString method of a VehicleId class containing a UUID would normally output this:
684ec9f4-b9f8-11ea-b3de-0242ac130004
But if you change the toString to include the aggregate type, you would get this:
VehichleId[684ec9f4-b9f8-11ea-b3de-0242ac130004]
Concluding, I think there are three main points I'd like to share:
Axon Framework did not intent to reuse Aggregate Streams to recreate distinct Aggregate types.
Polymoprhic Aggregates might be a means to resolve the scenario you have.
The [aggregateId, seqNo] uniqueness requirement can reuse an aggregateId as long is the toString method would append/prepend the aggregate type to the result.
I hope this helps you on your journey Lars. Please let me know of you feel something is missing or if I didn't grasp your question correctly.
According to Asynchronous programming in C++ (Windows Store apps):
// Explicit construction. (Not recommended)
// Pass the IAsyncOperation to a task constructor.
// task<DeviceInformationCollection^> deviceEnumTask(deviceOp);
// Recommended:
auto deviceEnumTask = create_task(deviceOp);
Why is assignment (create_task) preferred over construction?
I think you're just as bound either way. You're bound to the class you're constructing as well as the factory interface you may be using and subject to maintaining compatibility with whatever changes are made to the public interfaces utilitized in your implementation. Disruptive changes are just as possible in either location. Microsoft's answer to this question comes from the create_task() documentation: create_task() is just a convenience function as it allows the use of the 'auto' keyword while creating tasks. http://msdn.microsoft.com/en-us/library/vstudio/hh913025.aspx
I think the reason why using factories in general is more desirable rather than calling constructors is that this is less coupled with specific implementation of the interface. If you call constructor then your program is tightly coupled with given implementation.
Object construction with factories is less coupled, and also more flexible and extendable. For example, in the next version of the API providers might decide to deprecate certain implementation or replace it with something else. If you use only factory then they can simply change it's implementation to return instance of another class, or inject some more dependencies internally. But if your program is bound with specific class it would be much diffucult to achieve.
Which of the following would you go with?
And based on object oriented programming which one is the best practice?
A
Class Note
{
//Some properties, etc
public static Note getNoteFromServer();
public void UpdateNoteOnServer();
}
B
Class Note
{
//Some properties, etc
}
Class NoteManager
{
public static Note getNoteFromServer();
public static UpdateNoteOnServer(Note);
}
I would say option B. In that way you separate concerns: you have a Note that can be reused anywhere (and not necessarily on a networked application), and you have a manager class that only cares with server communication.
You may also think on implement logic for multiple servers. For example, you may want to comunicate with data formats like JSON or XML. You may implement an interface (example, interface INoteManager) and then implement two classes with servers for each of the data types I mentioned (example, NoteManagerXml and NoteManagerJson).
The main point on this question is sepration of concerns. Hope I've helped! :)
To take a different viewpoint from my other answer, I'd suggest that your division into Note/NoteManager is the wrong one - not because Note has anything wrong with it, but because the term Manager is a bit of a code smell because it's very generic, inviting the use of the class as a general dumping ground.
If the class is responsible for note persistence, call it NoteRepository.
If it's responsible for validating the content of a single note, move the logic onto the Note.
If it's responsible for creating notes, providing a number of convenience methods for easily creating notes, call it NoteFactory.
And if it's responsible for all of the above, split it into separate pieces because it's doing too much.
That's a pretty opinion based question you're asking there.
You're essentially asking (if I understand correctly) whether it is better to have a Class which contains only properties and another class to manage that object (Example B) or to have a class which does everything (Example A).
It really depends. If we're planning on using a MVC kind of framework, Example B would fit better, with Note being your Model, and NoteManager being the controller.
Personally, I would go with a hybrid of A and B, where NoteManager is handling controller actions, but the Model still has methods of its own to do things like managing a singleton instance. So maybe something like this?
Class Note
{
//Some properties, etc
public static Note getInstance(noteIdentifier);
public void saveNote();
}
Class NoteManager
{
// This handles view validation and calls Note.saveNote();
public static UpdateNoteOnServer(Note);
}
I think A is better, for 1 reason:
It implements the Object Oriented
paradigm to the letter.
The problem i see with B is that a static method that receives an instance of the same class sounds redundant to me because, why would you use a static method to apply behaviour to an instance of the same class? The whole idea behind classes and instances is that Classes are the frame and instances cookies, if you need different cookies, modify your frame and get new ones.
It seems to depend on how its going to be used in your program. If Note is the only class or is the parent class for derived classes then there is no point and having a "Manager", Keep It Simple Stupid (KISS). However if the Manager has to deal with other classes via Interfaces then I can see having a seperate class.
As per my experience best practice is , as long as things are separated DRY is best practice. you can extends note to notemanager
Class Note
{
//Some properties, etc
}
Class NoteManager
{
public static Note getNoteFromServer();
public static UpdateNoteOnServer(Note);
}
I'd choose B, unless you want to end up like poor ol' PHP:
get_note_from_server_and_print_the_response($note, 'PHP, why must you be so disorganized?')
But seriously, it may seem intuitive to do A at the moment, but you'll eventually split A up, as those server operations will require more and more related functions, until you have a mammoth Note class which contains every function in your program...
"It Depends"
One of the things it depends upon is the language of implementation.
If you are working in C# or Java, then you'll likely want to go with the Note/NoteManager approach as this gives you the most flexiblity of implementation - because static members in those languages a kind of second class citizens.
To illustrate, in Delphi's original Object Pascal lanaguage, methods and properties that could be accessed without an instance were known as class members, not static members, and they could be virtual, and therefore overridden in descendent classes.
If you're working with a language that provides features like "virtual class (static) members" and a few others, then you might want to merge Note/NoteManager together.
I would go with "B"
Reason why is that you may require "Note" to be used with another type of Controller class, like what you have done for NoteManager.
Also gives you the ability to dissociate your Data Objects or DTO's or Model away from your actual controller classes.
C
Class Note
{
//Some properties, etc
public static Note LoadFrom(Whatever);
public void SaveTo(Whatever);
}
Take for example:
CreateOrderTicket(ByVal items As List(Of OrderItems)) As String
Where would you put this sort of logic given:
CreateOrder should generate a simple list ( i.e. Item Name - Item Price )
PizzaOrderItem
SaladBarOrderItem
BarOrderItem
Would you recommend:
Refactoring common to an abstract class/interface with shared properties a method called CreateOrderTicket
Or,
Creating a common service that exposes a CreateOrderTicket
We obviously would not want three createOrderTicket methods, but adding methods, inheriting, overloading and using generics seem like a high cost just to abstract one behaviour..
Assume for the sake of a simple example that (currently) there is no OrderItem baseclass or interface..
Help!! :)
p.s. Is there a way to overload without forcing all inheriting objects to use the same name?
Abstract base class sounds like the best option in this situation. Of course it all depends on what kind of shared behaviour these items have. Without knowing more, I'd guess all of these order items have Name and Price for example - and in future you might add more common stuff.
Without a shared base class which contains the Name and Price properties, you'll probably have troubles implementing a CreateOrderTicket method which takes a list containing more than 1 kind of orders.
Also I don't think inheriting from an abstract base class would be that high cost as technically the objects already derive from the Object base class. (Though I don't think this is completely equal to a custom base class.)
VB.Net can implement methods from an interface using a different name than the one specified in the interface but don't think the same goes for overriding abstract functionality.