Perhaps I might be confused or misunderstanding some basic principles. When applying DDD in an Axon based event sourcing project, you define a number of aggregates each of them having several command handler methods verifying if a state change of the aggregate is valid and a corresponding collection of event handler methods applyling each requested state change.
EDIT START:
So an aggregate could look like
#Aggregate
public class Customer {
#AggregateIdentifier
private CustomerId customerId;
private Name name;
#CommandHandler
private Customer(CreateCustomerCommand command) {
AggregateLifecycle.apply(new CustomerCreatedEvent(
command.getCustomerId(), command.getName());
}
#EventSourcingHandler
private void handleEvent(CustomerCreatedEvent event) {
this.customerId = event.getCustomerId();
this.name = event.getName();
}
}
EDIT END
So my first question is: Am I correct to conclude the aggregate does not implement any state changing methods directly (typical public methods altering the properties of the aggregate instance) but all state changing methods are defined in a separate domain service interacting with Axon's command gateway?
EDIT START:
In other words, should an aggregate define setters responsible for sending a command to the framework which will result in the corresponding command handler and event handler being called by adding the code below to the aggregate?
public void setName(String name){
commandGateway.send(new UpdateNameCommand(this.customerId, name));
}
#CommandHandler
private void handleCommand(UpdateNameCommand command) {
AggregateLifecycle.apply(new NameUpdatedEvent(command.getCustomerId(), command.getName());
}
#EventSourcingHandler
private void handleEvent(NameUpdatedEvent event) {
this.name = event.getName();
}
This seems to violate some recommendations since a reference to the gateway is needed from within the aggregate.
Or do you typically define such methods in a separate service class which will then send the command to the framework.
#Service
public class CustomerService {
#Autowired
private CommandGateway gateway;
public void createCustomer(String name) {
CreateCustomerCommand command = new CreateCustomerCommand(name);
gateway.send(command);
}
public void changeName(CustomerId customerId, String name) {
UpdateNameCommand command = new UpdateNameCommand (customerId, name);
gateway.send(command);
}
}
This seems the correct approach to me. This seems to make (at least to my opinion) the aggregate's behavior not directly accessible for the outer world (all command and event handler methods can be made private) like a more "traditional" objects which are the entry-point for requesting state changes...
EDIT END
And secondly: Isn't this in contradiction with OOP principles of each class defining its (public) interface methods to interact with? In other words, doesn't this approach make an object a more or less dump object in which direct interaction is impossible?
Thanks for your feedback,
Kurt
So my first question is: Am I correct to conclude the aggregate does not implement any state changing methods directly (typical public methods altering the properties of the aggregate instance) but all state changing methods are defined in a separate domain service interacting with Axon's command gateway?
Absolutely not! The aggregate itself is responsible for any state changes.
Probably, the misconception is around the Command Handler (method) within the aggregate, when using event sourcing. In that case, the Command Handler (method) should not directly apply changes. Instead, it should apply an Event, which then invokes an Event Sourcing Handler (method) within that same aggregate instance to apply the state changes.
Whether using Event Sourcing or not, the aggregate should expose actions (e.g. Command Handlers) only, and make its decisions based on those actions. Preferably, the Aggregate (of a Command Handler) doesn't expose any state outside of the Aggregate boundaries.
And secondly: Isn't this in contradiction with OOP principles of each class defining its (public) interface methods to interact with? In other words, doesn't this approach make an object a more or less dump object in which direct interaction is impossible?
That would have been the case if the aggregate relied on external components to manage its state. But it doesn't.
additional reactions after question edit
So my first question is: Am I correct to conclude the aggregate does not implement any state-changing methods directly (typical public methods altering the properties of the aggregate instance) but all state changing methods are defined in a separate domain service interacting with Axon's command gateway?
I think it's exactly the opposite. The first aggregate in the question is an example of an aggregate that has all state changing operations inside of itself. Exposing setters to "change state" is a very bad idea. It forces the logic to decide on when to change this value outside of the Aggregate. That, in my opinion, is a "violation" of OOP.
Aggregates, in a DDD and/or CQRS context should no be instructed to change state. Instead, they should receive the actual business intent to react to. That is what a Command should reflect: the business intent. As a result, the Aggregate may change some attributes, but only to ensure that any commands happening after that behave in such a way that it reflects the things that have happened before. With event sourced aggregates, that has an extra intermediate step: applying an event. That needs to be done to ensure that sourcing an aggregate from past decisions yields the exact same state. Also note that these events are not "state change decisions", but "business decisions". The state changes are a result of that.
Final comments
The service class shown in the end would be the typical interaction. A component sending commands, not directly interacting with the Aggregate instance. However, the "UpdateNameCommand" as a comparison with the "setName" in the previous example put me off, since Commands should not be "C(R)UD" operations, but actual business operations. At may be the case that UpdateName is such a business operation.
Related
Background
Suppose I am tasked with building a system in the domain of notification sending using Domain Driven Design (DDD). One of the key requirements of this system is that it needs to support various "types" of notifications, such as SMS, email, etc.
After several iterations on developing the domain model, I continue to land on having a Notification base class as an entity, with subclasses SMSNotification, EmailNotification, etc. as child classes (each being an entity as well).
Notification
public abstract class Notification extends Entity<UUID> {
//...fields...
public abstract void send();
}
SMSNotification
public class SMSNotification extends Notification {
public void send(){
//logic for sending the SMS notification using an infrastructure service.
}
}
EmailNotification
public class EmailNotification extends Notification {
public void send(){
//logic for sending the email notification using an infrastructure service.
}
}
Problem(s)
With this current design approach, each subclass of Notification is interacting with an infrastructure service, where the infrastructure is tasked with interfacing with some external system.
Eric Evans dedicates a little page space about this on page 107 in his book Domain-Driven Design when introducing the concept of domain services:
..., in most development systems, it is awkward to make a direct interface between a domain object and external resources. We can dress up such external services with a facade that takes inputs in terms of the model, ... but whatever intermediaries we may have, and even though they don't belong to us, those services are carrying out the domain responsibility...
If instead, I procure a SendNotificationService in my domain model using Evans' advice instead of having a send method on each subclass of Notification, I am not sure how I can avoid the need for knowing what type of notification was provided, so that the appropriate infrastructure action can be taken:
SendNotificationService (Domain Service)
public class SendNotificationService {
public void send(Notification notification){
//if notification is an SMS notification...
// utilize infrastructure services for SMS sending.
//if notification is an email notification...
// utilize infrastructure services for email sending.
//
//(╯°□°）╯︵ ┻━┻)
}
}
What am I missing here?
Object oriented design principles are pushing me in favor of having the model first suggested, with the Notification, SMSNotification, and EmailNotification classes. Implementing the send method on each subclass of Notification makes sense, as all notifications need to be sent (justifies its placement in Notification) and each "type" or subclass of Notification will have specialized behavior in how the notification is sent (justifies making send abstract in Notification). This approach also honors Open/Closed Principle (OCP), since the Notification class will be closed to modification, and as new notification types are supported, a new subclass of Notification can be created to extend functionality. Regardless, there seems to be consensus on not having entities interface with external services, as well as not having subclasses of entities at all in DDD.
If the behavior of sending notifications is removed from Notification, then where it is placed must be aware of the "type" of notification, and act accordingly, which I can only conceptualize as chain of if...else... statements, which directly contradicts OCP.
TLDR: If you need some infrastructure logic to be executed against your domain and you need some input to it from domain - don't build it in, just declare intentions with appropriate data/markers. You'll then process this declared intentions later, in infrastructure layer.
Do notifications of various kind differ in any way other that delivery mechanism? If not - there could be enough to use a Notification value object (or Entity, if your domain model requires so) with additional field (Enum, if the list is known, or some kind of marker) to store a delivery method name. Maybe, there could be numerous such methods per single notification instance.
Then you have a business logic - a domain service - to fire a notification. A domain service should only depend on domain vocabulary. E.g NotificationDeliveryMethodProvider.
In your adapters layer you can implement various delivery method providers to interact with infrastructure. And a factory to get providers according to a value in DeliveryMethod enum (or marker).
Basically, it's not an aggregate's responsibility to "send" itself of manipulate in any way. Its responsibility should be to maintain its state, execute state transitions in a consistent way and coordinate states of its enclosed entities/values. And fire events about its state changes.
In one of my projects I used the following subpackages under my domain package:
provides - interfaces of domain services provided to clients
cousumes - interfaces of upstream dependencies
businesslogic - implementation of domain services
values - value objects with code to enforce their invariants
...
Besides domain package there were also:
adapters package dealing with infrastructure
App object, where all interfaces were bound to implementations.
[There could also be] config package, but in my case it was very light.
These domain, adapters, App and config could be deployed as different jar-files with clear dependency structure, if you need to enforce it for somebody other.
I agree with you that the main responsibility of a Notification should be, that it can send itself. That is the whole reason it exists, so it's a good abstraction.
public interface Notification {
void send();
}
The implementations of this interface are the infrastructure services you are looking for. They will not (should not) be referenced directly by other "business" or "core" classes.
Note about making in an Entity: My own takeaway from reading the blue book is, that DDD is not about using Entity, Services, Aggregate Roots, and things like that. The main points are Ubiquitous Language, Contexts, how to work the Domain itself. Eric Evans himself says that this thinking can be applied to different paradigms. It does not have to always involve the same technical things.
Note about the "conventional" design from the other comment (#VoiceOfUnreason): In object-orientation at least, "holding state" is not a real responsibility. Responsibilities can only directly come from the Ubiquitous Language, in other words from the business. "Conventional" (i.e. procedural) design separates data and function, object-orientation does exactly the opposite. So be sure to decide which paradigm you are aiming for, then it may be easier to choose a solution.
After several iterations on developing the domain model, I continue to land on having a Notification base class as an entity, with subclasses SMSNotification, EmailNotification, etc. as child classes
That's probably an error.
public abstract class Notification extends Entity<UUID> {
public abstract void send();
}
That almost certainly is. You can make it work, if you twist enough, but you are going the wrong way around.
The responsibility of the entities in your domain model is the management of state. To also have the entity be responsible for the side effect of dispatching a message across your process boundary violates separation of concerns. So there should be a collaborator.
For Evans, as you will have noted, the collaboration takes the form of a domain service, that will itself collaborate with an infrastructure service to produce the desired result.
The most straight forward way to give the entity access to the domain service is to simply pass the domain service as an argument.
public class SMSNotification extends Notification {
public void send(SMSNotificationService sms) {
//logic for sending the SMS notification using an infrastructure service.
}
The SMSNotification supports a collaboration with an SMSNoticationService provider, and we make that explicit.
The interface you've offered here looks more like the Command Pattern. If you wanted to make that work, you would normally wire up the specific implementations in the constructor
public class SMSCommand extends NotificationCommand {
private final SMSNotificationService sms;
private final SMSNotification notification;
public final send() {
notification.send(sms);
}
}
There are some things you can do with generics (depending on your language choice) that make the parallels between these different services more apparent. For example
public abstract class Notification<SERVICE> extends Entity<UUID> {
public abstract void send(SERVICE service);
}
public class SMSNotification extends Notification<SMSNotificationService> {
public void send(SMSNotificationService service){
//logic for sending the SMS notification using an infrastructure service.
}
}
public class NotificationCommand<SERVICE> {
private final SERVICE service;
private final Notification<SERVICE> notification;
public final send() {
notification.send(service);
}
}
That's the main approach.
An alternative that sometimes fits is to use the poor man's pattern match. Instead of passing in the specific service needed by a particular type of entity, you pass them all in....
public abstract class Notification extends Entity<UUID> {
public abstract void send(SMSNotificationService sms, EmailNotificationService email, ....);
}
and then let each implementation choose precisely what it needs. I wouldn't expect this pattern to be a good choice here, but it's an occasionally useful club to have in the bag.
Another approach that you will sometimes see is to have the required services injected into the entity when it is constructed
SMSNotificationFactory {
private final SMSNotificationService sms;
SMSNotification create(...) {
return new SMSNotification(sms, ...);
}
}
Again, a good club to have in the bag, but not a good fit for this use case -- you can do it, but suddenly a lot of extra components need to know about the notification services to get them where they need to be.
What's best between notification.send(service) and service.send(notification)
Probably
notification.send(service)
using "Tell, don't ask" as the justification. You pass the collaborator to the domain entity, and it decides (a) whether or not to collaborate, (b) what state to pass to the domain service, and (c) what to do with any state that gets returned.
SMSNotification::send(SMSNotificationService service {
State currentState = this.getCurrentState();
{
Message m = computeMessageFrom(currentState);
service.sendMessage(m);
}
}
At the boundaries, applications are not object oriented; I suspect that as we move from the core of the domain toward the domain, we see entities give way to values give way to more primitive representations.
after reading a bit on pure domain models and the fact there shouldn't be any IO in there I'm not sure anymore
It is, in truth, a bit of a tangle. One of the motivations of domain services is to decouple the domain model from the IO -- all of the IO concerns are handled by the domain service implementation (or more likely, by an application/infrastructure service that the domain service collaborates with). As far as the entity is concerned, the method involved is just a function.
An alternative approach is to create more separation between the concerns; you make the orchestration between the two parts explicit
List<SMSRequest> messages = domainEntity.getMessages();
List<SMSResult> results = sms.send(messages)
domainEntity.onSMS(results)
In this approach, all of the IO happens within the sms service itself; the interactions with the model are constrained to in memory representations. You've effectively got a protocol that's managing the changes in the model and the side effects at the boundary.
I feel that Evans is suggesting that service.send(notification) be the interface.
Horses for courses, I think -- passing an entity to a domain service responsible for orchestration of multiple changes within the model makes sense. I wouldn't choose that pattern for communicating state to/from the boundary within the context of a change to an aggregate.
Can you give any good explanation what is the difference between Proxy and Decorator?
The main difference I see is that when we assume that Proxy uses composition and Decorator uses aggregation then it seems to be clear that by using multiple (one or more) Decorators you can modify/ add functionalities to pre-existing instance (decorate), whereas Proxy has own inner instance of proxied class and delegates to it adding some additional features (proxy behaviour).
The question is - Does Proxy created with aggregation is still Proxy or rather Decorator? Is it allowed (by definition in GoF patterns) to create Proxy with aggregation?
The real difference is not ownership (composition versus aggregation), but rather type-information.
A Decorator is always passed its delegatee. A Proxy might create it himself, or he might have it injected.
But a Proxy always knows the (more) specific type of the delegatee. In other words, the Proxy and its delegatee will have the same base type, but the Proxy points to some derived type. A Decorator points to its own base type. Thus, the difference is in compile-time information about the type of the delegatee.
In a dynamic language, if the delegatee is injected and happens to have the same interface, then there is no difference.
The answer to your question is "Yes".
Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object.
EDIT:-
Relationship between a Proxy and the real subject is typically set at compile time, Proxy instantiates it in some way, whereas Decorator is assigned to the subject at runtime, knowing only subject's interface.
Here is the direct quote from the GoF (page 216).
Although decorators can have similar implementations as proxies, decorators have a different purpose. A decorator adds one or more responsibilities to an object, whereas a proxy controls access to an object.
Proxies vary in the degree to which they are implemented like a decorator. A
protection proxy might be implemented exactly like a decorator. On the other
hand, a remote proxy will not contain a direct reference to its real subject but only
an indirect reference, such as "host ID and local address on host." A virtual proxy
will start off with an indirect reference such as a file name but will eventually
obtain and use a direct reference.
Popular answers indicate that a Proxy knows the concrete type of its delegate. From this quote we can see that is not always true.
The difference between Proxy and Decorator according to the GoF is that Proxy restricts the client. Decorator does not. Proxy may restrict what a client does by controlling access to functionality; or it may restrict what a client knows by performing actions that are invisible and unknown to the client. Decorator does the opposite: it enhances what its delegate does in a way that is visible to clients.
We might say that Proxy is a black box while Decorator is a white box.
The composition relationship between wrapper and delegate is the wrong relationship to focus on when contrasting Proxy with Decorator, because composition is the feature these two patterns have in common. The relationship between wrapper and client is what differentiates these two patterns.
Decorator informs and empowers its client.
Proxy restricts and disempowers its client.
Decorator get reference for decorated object (usually through constructor) while Proxy responsible to do that by himself.
Proxy may not instantiate wrapping object at all (like this do ORMs to prevent unnecessary access to DB if object fields/getters are not used) while Decorator always hold link to actual wrapped instance.
Proxy usually used by frameworks to add security or caching/lazing and constructed by framework (not by regular developer itself).
Decorator usually used to add new behavior to old or legacy classes by developer itself based on interface rather then actual class (so it work on wide range of interface instances, Proxy is around concrete class).
Key differences:
Proxy provides the same interface. Decorator provides an enhanced interface.
Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.
Decorator can be viewed as a degenerate Composite with only one component. However, a Decorator adds additional responsibilities - it isn't intended for object aggregation.
Decorator supports recursive composition
The Decorator class declares a composition relationship to the LCD (Lowest Class Denominator) interface, and this data member is initialized in its constructor.
Use Proxy for lazy initialization, performance improvement by caching the object and controlling access to the client/caller
Sourcemaking article quotes the similarities and differences in excellent way.
Related SE questions/links:
When to Use the Decorator Pattern?
What is the exact difference between Adapter and Proxy patterns?
Proxy and Decorator differ in purpose and where they focus on the internal implementation. Proxy is for using a remote, cross process, or cross-network object as if it were a local object. Decorator is for adding new behavior to the original interface.
While both patterns are similar in structure, the bulk of the complexity of Proxy lies in ensuring proper communications with the source object. Decorator, on the other hand, focuses on the implementation of the added behavior.
Took a while to figure out this answer and what it really means. A few examples should make it more clear.
Proxy first:
public interface Authorization {
String getToken();
}
And :
// goes to the DB and gets a token for example
public class DBAuthorization implements Authorization {
#Override
public String getToken() {
return "DB-Token";
}
}
And there is a caller of this Authorization, a pretty dumb one:
class Caller {
void authenticatedUserAction(Authorization authorization) {
System.out.println("doing some action with : " + authorization.getToken());
}
}
Nothing un-usual so far, right? Obtain a token from a certain service, use that token. Now comes one more requirement to the picture, add logging: meaning log the token every time. It's simple for this case, just create a Proxy:
public class LoggingDBAuthorization implements Authorization {
private final DBAuthorization dbAuthorization = new DBAuthorization();
#Override
public String getToken() {
String token = dbAuthorization.getToken();
System.out.println("Got token : " + token);
return token;
}
}
How would we use that?
public static void main(String[] args) {
LoggingDBAuthorization loggingDBAuthorization = new LoggingDBAuthorization();
Caller caller = new Caller();
caller.authenticatedUserAction(loggingDBAuthorization);
}
Notice that LoggingDBAuthorization holds an instance of DBAuthorization. Both LoggingDBAuthorization and DBAuthorization implement Authorization.
A proxy will hold some concrete implementation (DBAuthorization) of the base interface (Authorization). In other words a Proxy knows exactly what is being proxied.
Decorator:
It starts pretty much the same as Proxy, with an interface:
public interface JobSeeker {
int interviewScore();
}
and an implementation of it:
class Newbie implements JobSeeker {
#Override
public int interviewScore() {
return 10;
}
}
And now we want to add a more experienced candidate, that adds it's interview score plus the one from another JobSeeker:
#RequiredArgsConstructor
public class TwoYearsInTheIndustry implements JobSeeker {
private final JobSeeker jobSeeker;
#Override
public int interviewScore() {
return jobSeeker.interviewScore() + 20;
}
}
Notice how I said that plus the one from another JobSeeker, not Newbie. A Decorator does not know exactly what it is decorating, it knows just the contract of that decorated instance (it knows about JobSeeker). Take note here that this is unlike a Proxy; that, in contrast, knows exactly what it is decorating.
You might question if there is actually any difference between the two design patterns in this case? What if we tried to write the Decorator as a Proxy?
public class TwoYearsInTheIndustry implements JobSeeker {
private final Newbie newbie = new Newbie();
#Override
public int interviewScore() {
return newbie.interviewScore() + 20;
}
}
This is definitely an option and highlights how close these patterns are; they are still intended for different scenarios as explained in the other answers.
A Decorator adds extra responsibility to an object, while a proxy controls access to an object, they both use composition. If your wrapper class messes with the subject, it is obviously a proxy. Let me explain by a code example in PHP:
Code Example
Given is the following CarRepository:
interface CarRepositoryInterface
{
public function getById(int $id) : Car
}
class CarRepository implements CarRepositoryInterface
{
public function getById(int $id) : Car
{
sleep(3); //... fake some heavy db call
$car = new Car;
$car->setId($id);
$car->setName("Mercedes Benz");
return $car;
}
}
CarRepository-Proxy
A Proxy is often used as lazy loading or a cache proxy:
class CarRepositoryCacheProxy implements CarRepositoryInterface
{
private $carRepository;
private function getSubject() : CarRepositoryInterface
{
if($this->carRepository == null) {
$this->carRepository = new CarRepository();
}
return $this->carRepository;
}
/**
* This method controls the access to the subject
* based on if there is cache available
*/
public function getById(int $id) : Car
{
if($this->hasCache(__METHOD__)) {
return unserialize($this->getCache(__METHOD__));
}
$response = $this->getSubject()->getById($id);
$this->writeCache(__METHOD__, serialize($response));
return $response;
}
private function hasCache(string $key) : bool
{
//... implementation
}
private function getCache(string $key) : string
{
//... implementation
}
private function writeCache(string $key, string $result) : string
{
//... implementation
}
}
CarRepository-Decorator
A Decorator can be used as long as the added behavior does not "control" the subject:
class CarRepositoryEventManagerDecorator implements CarRepositoryInterface
{
private $subject, $eventManager;
/**
* Subjects in decorators are often passed in the constructor,
* where a proxy often takes control over the invocation behavior
* somewhere else
*/
public function __construct(CarRepositoryInterface $subject, EventManager $eventManager)
{
$this->subject = $subject;
$this->eventManager = $eventManager;
}
public function getById(int $id) : Car
{
$this->eventManager->trigger("pre.getById");
//this method takes no control over the subject
$result = $this->subject->getById($id);
$this->eventManager->trigger("post.getById");
return $result;
}
}
Proxy provides the same interface to the wrapped object, Decorator provides it with an enhanced interface, and Proxy usually manages the life cycle of its service object on its own, whereas the composition of Decorators is always controlled by the client.
Let me explain the patterns first and then come to you questions.
From the class diagram and meanings, they are very similar:
Both have the same interface as its delegatee has.
Both add/enhance the behavior of its delegatee.
Both ask the delegatee to perform operations(Should not work with null delegatee).
But they have some difference:
Different intents:
Proxy enhances the behavior of delegatee(passed object) with quite different domain knowledge from its delegatee. Eg, a security proxy adds security control of the delegatee. A proxy to send remote message needs to serialize/deserialize data and has knowlege on network interfacing, but has nothing to do with how to prepare source data.
Decorator helps on the same problem domain the delegatee works on. Eg, BufferedInputStreaman(an IO decorator) works on input, which is the same problem domain(IO) as its delegatee, but it cannot perform without a delegatee which provides IO data.
Dependency is strong or not:
Decorator relies on delegate to finish the behavior, and it cannot finish the behavior without delegatee(Strong). Thus we always use aggration over composition.
Proxy can perform faked behavior even it does not need a delegatee(Weak). Eg, mockito(unit test framework) could mock/spy a behavior just with its interface. Thus we use composition to indicate there's no strong dependency on real object.
Enhance multipletimes(as mentioned in question):
Proxy: we could utilize proxy to wrap real object once not several times.
Decorator: A decorator can wrap the real object several times or can wrap the object which is already wrapped by a decorator(which could be both a different decorator or the same decorator). Eg, for an order system, you can do discount with decorators.
PercentageDiscountDecorator is to cut 50% off, and DeductionAmountDiscountDecorator is to deduct 5$ directly if the amount is greater than 10$(). So,
1). When you want to cut 50% off and deduct 5$, you can do: new DeductionAmountDiscountDecorator(new PercentageDiscountDecorator(delegatee))
2). When you want to deduct 10$, you can do new DeductionAmountDiscountDecorator(new DeductionAmountDiscountDecorator(delegatee)).
The answer to the question has nothing to do with the difference between Proxy and Decorator. Why?
Design patterns just patterns for people who are not good at OO skills to make use of OO solutions. If you are familiar with OO, you don't need to know how many design patterns there(Before design patterns invented, with the same prolbem skilled people could figure out the same solution).
No two leaves are exactly the same, so as the problems you encount. People will always find their problems are different from the problems given by design patterns.
If your specified problem is really different from both problems that Proxy and Decorator work on, and really needs an aggregation, why not to use? I think to apply OO to your problem is much more important than you label it a Proxy or Decorator.
Still experimenting with DDD and have some doubts, maybe someone would help me.
Lets say that I have 2 models:
public class Event
{
User Creator;
List<User> Members;
}
public class User {}
My problem is that I cannot see place for logic that I want to implement. I need 3 actions:
User join event
User leave event
Creator remove user from event (only Creator can remove users)
For now I just created domain service EventUserService that calls Event.RemoveUser/AddUser and ie. checks if CurrentUser (provided by UserService) is creator of event (have rights to remove other users).
Maybe that approach is ok, but I still feel that I should putt that logic into aggregation roots, ie. :
User.JoinEvent(Event) - i can add passed Event to User.Events collection (bidirectionall) base on some logic.
User.LeaveEvent(Event) - analogous to JoinEvent.
User.RemoveUserFromEvent(User,Event) - I can have CreatedEvents collection in User and for Event from that collection I can call Event.RemoveUser(User) - this way I will make sure that only creator can kick someone.
Or
Evet.RemoveUser(UserToRemove) - but how I will make sure that its called by creator ?
If first two method looks ok (at least for me), 3rd one would create Event.RemoveUser (to manage Event members collection) method that could be used to bypass logic residing in User.RemoveUserFromEvent.
So, in the end I have 2 questions:
What is your approach in situation like this where two aggregation roots works together and one operation is determine by logic residing in both of them? Maybe some kind of methoods like User.CanJoinEvent(Event) ?
What about creating "danger" point like User.RemoveUserFromEvent
Maybe someone can putt a little bit light on that for me, every help would be nice.
public class Event
{
User Creator;
List<User> Members;
}
Don't do that. You are breaking Law Of Demeter and the Event class has no control over the changes in Members or the users in that list. You should instead define methods in the Event class which is used to handle the members.
Now, if you do that change, i.e. have something like this:
public class Event
{
User Creator { get private set; }
bool IsMember(string name);
void AddMember(User user);
}
You'll suddenly have solid places to generate the events.
but how I will make sure that its called by creator ?
In .NET you can use Thread.CurrentPrinicpal to get information about the logged in user. It do however require that you implement your own IPrincipal/IIdentity.
Remember: You should ALWAYS make sure that the models are in a valid state in DDD. That usually means that all setters should be private: http://blog.gauffin.org/2012/06/protect-your-data/
Following advices from people on the internet about service references, I got rid of them now and split the service/data contracts into a common assembly accesible by both the server and the client. Overall this seems to work really well.
However I’m running into problems when trying to use custom objects, or rather custom subtypes, in the service. Initially I wanted to define only interfaces in the common assembly as the contract for the data. I quickly learned that this won’t work though because the client needs a concrete class to instantiate objects when receiving objects from the service. So instead I used a simple class instead, basically like this:
// (defined in the common assembly)
public class TestObject
{
public string Value { get; set; }
}
Then in the service contract (interface), I have a method that returns such an object.
Now if I simply create such an object in the service implementation and return it, it works just fine. However I want to define a subtype of it in the service (or the underlying business logic), that defines a few more things (for example methods for database access, or just some methods that work on the objects).
So for simplicity, the subtype looks like this:
// (defined on the server)
public class DbTestObject : TestObject
{
public string Value { get; set; }
public DbTestObject(string val)
{
Value = val;
}
}
And in the service, instead of creating a TestObject, I create the subtype and return it:
public TestObject GetTestObject()
{
return new DbTestObject("foobar");
}
If I run this now, and make the client call GetTestObject, then I immediately get a CommunicationException with the following error text: “The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:09:59.9380000'.”
I already found out, that the reason for this is that the client does not know how to deserialize the DbTestObject. One solution would be to declare the base type with the KnownTypeAttribute to make it know about the subtype. But that would require the subtype to be moved into the common assembly, which is of course something I want to avoid, as I want the logic separated from the client.
Is there a way to tell the client to only use the TestObject type for deserialization; or would the solution for this be to use data transfer objects anyway?
As #Sixto Saez has pointed out, inheritance and WCF don't tend to go together very well. The reason is that inheritance belongs very much to the OO world and not the messaging passing world.
Having said that, if you are in control of both ends of the service, KnownType permits you to escape the constraints of message passing and leverage the benefits of inheritance. To avoid taking the dependency you can utilise the ability of the KnownTypeAttribute to take a method name, rather than a type parameter. This allows you to dynamically specify the known types at run time.
E.g.
[KnownType("GetKnownTestObjects")]
[DataContract]
public class TestObject
{
[DataMember]
public string Value { get; set; }
public static IEnumerable<Type> GetKnownTestObjects()
{
return Registry.GetKnown<TestObject>();
}
}
Using this technique, you can effectively invert the dependency.
Registry is a simple class that allows other assemblies to register types at run-time as being subtypes of the specified base class. This task can be performed when the application bootstraps itself and if you wish can be done, for instance, by reflecting across the types in the assembly(ies) containing your subtypes.
This achieves your goal of allowing subtypes to be handled correctly without the TestObject assembly needing to take a reference on the subtype assembly(ies).
I have used this technique successfully in 'closed loop' applications where both the client and server are controlled. You should note that this technique is a little slower because calls to your GetKnownTestObjects method have to be made repeatedly at both ends while serialising/deserialising. However, if you're prepared to live with this slight downside it is a fairly clean way of providing generic web services using WCF. It also eliminates the need for all those 'KnownTypeAttributes' specifying actual types.
I'm trying to embrace widespread dependency injection/IoC. As I read more and more about the benefits I can certainly appreciate them, however I am concerned that in some cases that embracing the dependency injection pattern might lead me to create flexibility at the expense of being able to limit risk by encapsulating controls on what the system is capable of doing and what mistakes I or another programmer on the project are capable of making. I suspect I'm missing something in the pattern that addresses my concerns and am hoping someone can point it out.
Here's a simplified example of what concerns me. Suppose I have a method NotifyAdmins on a Notification class and that I use this method to distribute very sensitive information to users that have been defined as administrators in the application. The information might be distributed by fax, email, IM, etc. based on user-defined settings. This method needs to retrieve a list of administrators. Historically, I would encapsulate building the set of administrators in the method with a call to an AdminSet class, or a call to a UserSet class that asks for a set of user objects that are administrators, or even via direct call(s) to the database. Then, I can call the method Notification.NotifyAdmins without fear of accidentally sending sensitive information to non-administrators.
I believe dependency injection calls for me to take an admin list as a parameter (in one form or another). This does facilitate testing, however, what's to prevent me from making a foolish mistake in calling code and passing in a set of NonAdmins? If I don't inject the set, I can only accidentally email the wrong people with mistakes in one or two fixed places. If I do inject the set aren't I exposed to making this mistake everywhere I call the method and inject the set of administrators? Am I doing something wrong? Are there facilities in the IoC frameworks that allow you to specify these kinds of constraints but still use dependency injection?
Thanks.
You need to reverse your thinking.
If you have a service/class that is supposed to mail out private information to admins only, instead of passing a list of admins to this service, instead you pass another service from which the class can retrieve the list of admins.
Yes, you still have the possibility of making a mistake, but this code:
AdminProvider provider = new AdminProvider();
Notification notify = new Notification(provider);
notify.Execute();
is harder to get wrong than this:
String[] admins = new String[] { "joenormal#hotmail.com" };
Notification notify = new Notification(admins);
notify.Execute();
In the first case, the methods and classes involved would clearly be named in such a way that it would be easy to spot a mistake.
Internally in your Execute method, the code might look like this:
List<String> admins = _AdminProvider.GetAdmins();
...
If, for some reason, the code looks like this:
List<String> admins = _AdminProvider.GetAllUserEmails();
then you have a problem, but that should be easy to spot.
No, dependency injection does not require you to pass the admin list as a parameter. I think you are slightly misunderstanding it. However, in your example, it would involve you injecting the AdminSet instance that your Notification class uses to build its admin list. This would then enable you to mock out this object to test the Notification class in isolation.
Dependencies are generally injected at the time a class is instantiated, using one of these methods: constructor injection (passing dependent class instances in the class's constructor), property injecion (setting the dependent class instances as properties) or something else (e.g. making all injectable objects implement a particular interface that allows the IOC container to call a single method that injects its dependencies. They are not generally injected into each method call as you suggest.
Other good answers have already been given, but I'd like to add this:
You can be both open for extensibility (following the Open/Closed Principle) and still protect sensitive assets. One good way is by using the Specification pattern.
In this case, you could pass in a completely arbitrary list of users, but then filter those users by an AdminSpecification so that only Administrators recieve the notification.
Perhaps your Notification class would have an API similar to this:
public class Notification
{
private readonly string message;
public Notification(string message)
{
this.message = message;
this.AdminSpecification = new AdminSpecification();
}
public ISpecification AdminSpecification { get; set; }
public void SendTo(IEnumerable users)
{
foreach(var u in users.Where(this.AdminSpecification.IsSatisfiedBy))
{
this.Notify(u);
}
}
// more members
}
You can still override the filtering behavior for testing-purposes by assigning a differet Specification, but the default value is secure, so you would be less likely to make mistakes with this API.
For even better protection, you could wrap this whole implementation behind a Facade interface.