headers
Eben Roux | 1 Aug 12:02
Picon

Re: Domain events - do they contain the domain object or an id?

Hi Pat,

I don't know if you read my take on the whole cqs / events / messages post, but if one truly has a need to keep
messages within the domain scope I guess it would be OK to send around a real domain object (or any object,
for that matter) since it would not require any serialization.  For anything going across the wire,
though, you are absolutely correct regarding the identifier.

However, I am still waiting for input as to whether there really are ever such 'events' or messages.

Regards,
Eben

------------------------------------
Permalink | Reply | 2 comments |
headers
Udi Dahan | 2 Aug 13:34
Picon

RE: Re: Domain events - do they contain the domain object or an id?

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q ="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="h ttp://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/ relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">



Pat, Eben,

 

Within a given bounded context, domain events can and indeed should pass the domain object around by reference.

Between bounded contexts, events passing on a kind of bus should contain primarily (if not only) IDs.

 

With thanks,

 

-- Udi Dahan

 

From: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of Eben Roux
Sent: Saturday, August 01, 2009 1:02 PM
To: domaindrivendesign <at> yahoogroups.com
Subject: [domaindrivendesign] Re: Domain events - do they contain the domain object or an id?

 

 

Hi Pat,

I don't know if you read my take on the whole cqs / events / messages post, but if one truly has a need to keep messages within the domain scope I guess it would be OK to send around a real domain object (or any object, for that matter) since it would not require any serialization. For anything going across the wire, though, you are absolutely correct regarding the identifier.

However, I am still waiting for input as to whether there really are ever such 'events' or messages.

Regards,
Eben



__._,_.___


Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 1 comment |
headers
Udi Dahan | 2 Aug 13:36
Picon

RE: Pooling in DDD

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q ="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="h ttp://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/ relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">



To tell you the truth, the Messaging BC doesn't sound very much like a bounded context - sounds like more of an adapter to the 3rd party component.

 

-- Udi Dahan

 

From: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of Ben Ellis
Sent: Friday, July 31, 2009 7:03 PM
To: domaindrivendesign <at> yahoogroups.com
Subject: [domaindrivendesign] Pooling in DDD

 

 

I'm working with Sms Solutions, We have a Campaigning BC and a Messaging BC. In the Campaign BC users can Add Campaigns and Add Sms Messages to a Campaign. When an SmsMessage is due to be Sent, the IMessageSender service is triggered in the infrastructure layer of the Campaigning BC.

 

The IMessageSender sends a message to the MessagingBC which is responsible for Routing and Sending SmsMessages.

 

In the Messaging BC, There are 4 entities, Route, SmsMessage, Connection and Provider. A Route is currently an aggregate that has one or more Connections that are used to send SmsMessages to a Provider.

 

However, I am wanting to use a pooling mechanism such that I can pool and throttle Connections to a Provider.

 

Can I put pooling logic inside of Route so it pools its own Connections, or does this logic belong in the infrastructure layer? Further to this, the actual action of sending an Sms is done by a third party component, so for each instance of Connection I would need an instance of the third party component. How best can I seperate the third party component from the business/domain logic and into the infrastructure layer?

 

              --  Ben

 

 

 

From: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of jeremie.chassaing
Sent: 31 July 2009 16:09
To: domaindrivendesign <at> yahoogroups.com
Subject: [domaindrivendesign] Re: Designing a content management system

 

> This leads to another issue: Say a folder contains thousands of
> documents. In order to update a single document I need to either:
> 1. Maintain entities' change-state (new/updated/removed) and then loop
> through all child-entities when updating an aggregate-root.
> 2. Have repositories for child-entities which can be used to update
> individual child-entities (perhaps using a simple unit-of-work pattern)

Actually, the important thing in the Folder entity is which documents
are in it. Not document content. You could store association in the Folder Aggregate, but not Document content.

If a Document can only be in one Folder, you can have the relation only in the Document : you'll have a Folder property on the Document, and a MoveTo(Folder) method.

Listing Documents from a Folder will be considered as reporting.

> >
> > Wooo, there's a lot to reply since I switch off my computer
> yesterday...
> >
> > Let's start in order...
> >
> > 1.
> > >I don't quite understand what you mean with a domain >containing
> "technical terms" but whose "implementation
> > >in the domain will be different from their usual implementation".
> >
> > Your domains contains the Folder and Document terms, but the mapping
> from your Folder entity to an Folder in the operating system, or from
> your document entity to a File in the operating system is outside the
> > scope of your entities.
> >
> > 2.
> > > the Aggregate pattern, in this case, seems to contradict
> > > the PI concept
> >
> > Mh, I don't see why. The aggregate contains everything needed to
> > perform actions (that will lead to state changes) on them.
> > The repository is responsible to gather everything on aggregate root
> load, and store new state(or state changes events when doing event
> sourcing).
> >
> > >Among the things I don't like about this;
> > >1. you've now exposed details about how a Message's send() method is
> > >implemented to the caller (ie it needs an EmailService)
> > >2. you've made it the responsibility of the caller to have to
> > >provide this EmailService
> > >3. passing in the service as a parameter seems like false scoping:
> > > it suggests that the service may vary on an invocation-by-
> > > invocation basis, whereas in practice it will not
> >
> > Jesper gave very good answers to those points :
> > http://tech.groups.yahoo.com/group/domaindrivendesign/message/14363
> > especially for 3. Nothing prevents your message to be sent through
> > different implementations.
> > Jesper is also right that EmailService is not a good example.
> > You would prefer a IMessageSender (that gives no clue on the
> underlying messaging technology). You can have an EmailMessageSender, a
> FaxMessageSend (ok ol'school), a TwitterMessageSender (new school !),
> CellPhoneMessageSender etc.
> > You can even call twice Send with two or three implementations in a
> row to notify user using different media.
> >
> > >In the bounded context of sending email, is the domain model
> > >really appropriate?
> > >What's wrong with the simpler transaction script approach,
> > >especially given that we're not really persisting anything?
> >
> > Udi is right on this.
> > Actally I would not put a Send(...) method on the entity anymore.
> > The reason is that entity should only provide methods that change
> > its state.
> > I would gather the entity state from the Query context, and build
> > a command with it thas would be sent to the MessagingSender (this
> > is a service, it is stateless.).
> > If the message should be sent on an entity state change, the entity
> will publish its state change, a event handler you catch it, and send a
> command to the MessagingSender .
> > But there is still no injection in the entity.
> >
> > >I don't see also any reason why the domain object should never
> > >call the repository if necessary. Repository is a domain concept,
> > >so is just a domain concept making use of another domain concept.
> > I've never seen the need to use a repository inside an aggregate..
> > The aggregate boundary is especially designed so that you don't need
> > things from outside.
> >
> >
> > Here is my vision on the problem.
> >
> >
> >
> >
> >
> > --- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes nbplopes <at> wrote:
> > >
> > > There is nothing wrong with it. But in in some situations one may
> benefit
> > > from a "domain model", especially regarding the message (templates
> etc etc).
> > > Just sending is a function.
> > > The problem/question was more if it was good or bad injecting
> services
> > > into the domain object.
> > > I think the sending an email was more of a pretext to fire the
> conversation.
> > >
> > > Nuno
> > >
> > > On Fri, Jul 31, 2009 at 7:35 AM, Udi Dahan
> thesoftwaresimplist <at> wrote:
> > >
> > > >
> > > >
> > > > In the bounded context of sending email, is the domain model
> really
> > > > appropriate?
> > > >
> > > > What's wrong with the simpler transaction script approach,
> especially given
> > > > that we're not really persisting anything?
> > > >
> > > >
> > > >
> > > > -- Udi Dahan
> > > >
> > > >
> > > >
> > > > *From:* domaindrivendesign <at> yahoogroups.com [mailto:
> > > > domaindrivendesign <at> yahoogroups.com] *On Behalf Of *Jesper De
> Temmerman
> > > > *Sent:* Friday, July 31, 2009 9:07 AM
> > > > *To:* domaindrivendesign <at> yahoogroups.com
> > > > *Subject:* Re: [domaindrivendesign] Re: Designing a content
> management
> > > > system
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > So instead of:
> > > > >
> > > > > public class Message {
> > > > > public void send() {
> > > > > emailService.sendEmail( ... );
> > > > > }
> > > > > EmailService emailService;
> > > > > voic setEmailService(EmailService emailService) { ... }
> > > > > }
> > > > >
> > > > > you recommend:
> > > > >
> > > > > public class Message {
> > > > > public void send(EmailService emailservice) {
> > > > > emailService.sendEmail( ... );
> > > > > }
> > > > > }
> > > >
> > > > (I don't like the Service name, it reminds me of service layer
> classes. I'd
> > > > call this an EmailSender)
> > > >
> > > > > Among the things I don't like about this;
> > > > > 1. you've now exposed details about how a Message's send()
> method is
> > > > > implemented to the caller (ie it needs an EmailService)
> > > >
> > > > No matter what you do, you'll expose those details because
> fundamentally,
> > > > you need a way to set that EmailService. If you use some private
> field
> > > > reflection trick for this you're even doing more harm because:
> > > > a) the requirement on the message class it is not evident from the
> > > > interface of that class anymore.
> > > > b) your message class cannot change its internal (hidden) state:
> you break
> > > > reflection by changing that field name.
> > > > c) you _cannot_ reuse your message without documenting that there
> is an
> > > > internal private variable named emailService that you need to set.
> > > > d) you cannot change the implementation of the service.
> > > >
> > > > With the send(IEmailSender sender) code you're calling a send and
> you know
> > > > that it is sent via the supplied sender. If you want to use it,
> you HAVE to
> > > > supply a sender.
> > > >
> > > > > 2. you've made it the responsibility of the caller to have to
> provide
> > > > this
> > > > > EmailService
> > > >
> > > > Agreed, but I don't really see anything wrong with that. Why would
> the
> > > > caller create a message and not know how to send it? And even if
> the caller
> > > > does not know where to get an EmailSender, there could be a
> service locator
> > > > that does now. This keeps your responsibilities nice and separate
> too.
> > > >
> > > > > 3. passing in the service as a parameter seems like false
> scoping: it
> > > > > suggests that the service may vary on an
> invocation-by-invocation basis,
> > > > > whereas in practice it will not
> > > >
> > > > It won't - in a lot of applications at least. But during the
> lifetime of
> > > > your application it surely can. If you interface via an
> IEmailSender, the
> > > > details of that sender can vary. Maybe your sender wants to
> support a new
> > > > SMTP protocol? Maybe you actually want to use different senders
> depending on
> > > > where the mail is going (mail to employees = bypass spam filter,
> mail to
> > > > external = run virus scan)?
> > > >
> > > >
> > > >
> > > >
> > >
> >
>



__._,_.___


Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 5 comments |
headers
Eben Roux | 3 Aug 06:47
Picon

Re: Domain events - do they contain the domain object or an id?

Hi Udi,

While we're on the subject.

Are these domain events really necessary?

Let's take your GameReportedLost event.  If nothing is listening to that event then everything carries on
and the game is, say, not added to the cart.  Strange behaviour would result.  I know one could argue that
something *should* be listening, but the explicit failure of the AddGameToCart process is removed. 
Maybe this scenario does not result in an explicit failure.  But if it does, how would a process be stopped
after sending the event?  Guess it can't so a domain event is then fire-and-forget.  But still; why?  Is the
domain not an explicit implementation of the business requirement?

I can understand when there is a GameReportedLost message sent on a messagebus that another bounded
context can listen to and then *it* decides whether to, say, bill a client and then whether to order a new copy.

I don't quite get why it would be needed within the domain though.  What am I missing?

Regards,
Eben

--- In domaindrivendesign <at> yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:
>
> Pat, Eben,
> 
>  
> 
> Within a given bounded context, domain events can and indeed should pass the
> domain object around by reference.
> 
> Between bounded contexts, events passing on a kind of bus should contain
> primarily (if not only) IDs.
> 
>  
> 
> With thanks,
> 
>  
> 
> -- Udi Dahan
> 
>  
> 
> From: domaindrivendesign <at> yahoogroups.com
> [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of Eben Roux
> Sent: Saturday, August 01, 2009 1:02 PM
> To: domaindrivendesign <at> yahoogroups.com
> Subject: [domaindrivendesign] Re: Domain events - do they contain the domain
> object or an id?
> 
>  
> 
>   
> 
> Hi Pat,
> 
> I don't know if you read my take on the whole cqs / events / messages post,
> but if one truly has a need to keep messages within the domain scope I guess
> it would be OK to send around a real domain object (or any object, for that
> matter) since it would not require any serialization. For anything going
> across the wire, though, you are absolutely correct regarding the
> identifier.
> 
> However, I am still waiting for input as to whether there really are ever
> such 'events' or messages.
> 
> Regards,
> Eben
>

------------------------------------
Permalink | Reply | 0 comments |
headers
Jesper De Temmerman | 3 Aug 08:07
Picon

Re: Persistence concerns seem to be forcing identity onto some of my value objects



It's been a while since I worked on that specific project, but what we had were a set of classes that used the same data but used that data in different ways. Think of it as having three fields that are used to calculate a certain value: instead of having one object with CalculateA, CalculateB and CalculateC methods we had a common superclass and the subclasses A, B and C implemented the Calculate-method.

Our database contained the the data columns and one additional column that identified the specific class used (A, B or C). This data was read by our implementation of the ICompositeUserType-interface and used to create the specific class. We could not use components because we needed to execute SOME logic to determine the subclass type, and I think we opted not to use the NHibernate inheritance mapping features to avoid having the Id's - we wanted to deal with value objects.


> Thanks for the feedback Jesper.
> As far as NHibernate in general, I was a believer about 2 days in.
> Fortunately, I'd worked with ORM before so I didn't need to be convinced
> on
> that score.
>
> I agree that entity ID's have meaning outside of persistence but in the
> case
> of value objects, like my ColorSource example, the ID is only relevant as
> a
> persistence concern. Do your value objects have ID's that have a meaning
> aside from persistence?
>
> I know that IUserType and ICompositeUserType exist but that's about it.
> What kinds of mapping problems have you solved
> with IUserType/ICompositeUserType?

<at> toron.be>

__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 0 comments |
headers
Ben Ellis | 3 Aug 12:26
Picon

RE: Pooling in DDD



Udi,
 
        I have business logic around which route a message should be sent (based on customer profile, security settings and the message destination). For example, customers who pay for cheap messaging get routed via one of our cheap providers, while customers who pay for priority messaging get routed via another provider, additionally, Messages are routed differently depending on their destination (i.e. inside the UK and Ireland or outside the UK).
 
        Does the fact I have domain logic around the routing not warrant a Messaging/Routing BC?
 
        Messages can currently be sent to Providers either via an SmppConnection or HttpConnection. (SMPP = Short Message Peer-2peer Protocol used for sending Short Messageing Service (SMS) messages)
 
        In regards to Smpp, I have already written an adapter for the third party Smpp Component. After some thought over the weekend, it seems obvious that I should have a SmppMessagingSender service in the infrastructure layer and let the pooling and sending take place within the implementation. Does this sound correct?
 
        Regards,
 
                Ben
 
       

From: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of Udi Dahan
Sent: 02 August 2009 12:36
To: domaindrivendesign <at> yahoogroups.com
Subject: RE: [domaindrivendesign] Pooling in DDD

 

To tell you the truth, the Messaging BC doesn't sound very much like a bounded context - sounds like more of an adapter to the 3rd party component.

-- Udi Dahan

From: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of Ben Ellis
Sent: Friday, July 31, 2009 7:03 PM
To: domaindrivendesign <at> yahoogroups.com
Subject: [domaindrivendesign] Pooling in DDD

 

I'm working with Sms Solutions, We have a Campaigning BC and a Messaging BC. In the Campaign BC users can Add Campaigns and Add Sms Messages to a Campaign. When an SmsMessage is due to be Sent, the IMessageSender service is triggered in the infrastructure layer of the Campaigning BC.

The IMessageSender sends a message to the MessagingBC which is responsible for Routing and Sending SmsMessages.

In the Messaging BC, There are 4 entities, Route, SmsMessage, Connection and Provider. A Route is currently an aggregate that has one or more Connections that are used to send SmsMessages to a Provider.

However, I am wanting to use a pooling mechanism such that I can pool and throttle Connections to a Provider.

Can I put pooling logic inside of Route so it pools its own Connections, or does this logic belong in the infrastructure layer? Further to this, the actual action of sending an Sms is done by a third party component, so for each instance of Connection I would need an instance of the third party component. How best can I seperate the third party component from the business/domain logic and into the infrastructure layer?

              --  Ben

From: domaindrivendesign <at> yahoogroups.com [mailto:domaindrivendesign <at> yahoogroups.com] On Behalf Of jeremie.chassaing
Sent: 31 July 2009 16:09
To: domaindrivendesign <at> yahoogroups.com
Subject: [domaindrivendesign] Re: Designing a content management system

 

> This leads to another issue: Say a folder contains thousands of
> documents. In order to update a single document I need to either:
> 1. Maintain entities' change-state (new/updated/removed) and then loop
> through all child-entities when updating an aggregate-root.
> 2. Have repositories for child-entities which can be used to update
> individual child-entities (perhaps using a simple unit-of-work pattern)

Actually, the important thing in the Folder entity is which documents
are in it. Not document content. You could store association in the Folder Aggregate, but not Document content.

If a Document can only be in one Folder, you can have the relation only in the Document : you'll have a Folder property on the Document, and a MoveTo(Folder) method.

Listing Documents from a Folder will be considered as reporting.

> >
> > Wooo, there's a lot to reply since I switch off my computer
> yesterday...
> >
> > Let's start in order...
> >
> > 1.
> > >I don't quite understand what you mean with a domain >containing
> "technical terms" but whose "implementation
> > >in the domain will be different from their usual implementation".
> >
> > Your domains contains the Folder and Document terms, but the mapping
> from your Folder entity to an Folder in the operating system, or from
> your document entity to a File in the operating system is outside the
> > scope of your entities.
> >
> > 2.
> > > the Aggregate pattern, in this case, seems to contradict
> > > the PI concept
> >
> > Mh, I don't see why. The aggregate contains everything needed to
> > perform actions (that will lead to state changes) on them.
> > The repository is responsible to gather everything on aggregate root
> load, and store new state(or state changes events when doing event
> sourcing).
> >
> > >Among the things I don't like about this;
> > >1. you've now exposed details about how a Message's send() method is
> > >implemented to the caller (ie it needs an EmailService)
> > >2. you've made it the responsibility of the caller to have to
> > >provide this EmailService
> > >3. passing in the service as a parameter seems like false scoping:
> > > it suggests that the service may vary on an invocation-by-
> > > invocation basis, whereas in practice it will not
> >
> > Jesper gave very good answers to those points :
> > http://tech.groups.yahoo.com/group/domaindrivendesign/message/14363
> > especially for 3. Nothing prevents your message to be sent through
> > different implementations.
> > Jesper is also right that EmailService is not a good example.
> > You would prefer a IMessageSender (that gives no clue on the
> underlying messaging technology). You can have an EmailMessageSender, a
> FaxMessageSend (ok ol'school), a TwitterMessageSender (new school !),
> CellPhoneMessageSender etc.
> > You can even call twice Send with two or three implementations in a
> row to notify user using different media.
> >
> > >In the bounded context of sending email, is the domain model
> > >really appropriate?
> > >What's wrong with the simpler transaction script approach,
> > >especially given that we're not really persisting anything?
> >
> > Udi is right on this.
> > Actally I would not put a Send(...) method on the entity anymore.
> > The reason is that entity should only provide methods that change
> > its state.
> > I would gather the entity state from the Query context, and build
> > a command with it thas would be sent to the MessagingSender (this
> > is a service, it is stateless.).
> > If the message should be sent on an entity state change, the entity
> will publish its state change, a event handler you catch it, and send a
> command to the MessagingSender .
> > But there is still no injection in the entity.
> >
> > >I don't see also any reason why the domain object should never
> > >call the repository if necessary. Repository is a domain concept,
> > >so is just a domain concept making use of another domain concept.
> > I've never seen the need to use a repository inside an aggregate..
> > The aggregate boundary is especially designed so that you don't need
> > things from outside.
> >
> >
> > Here is my vision on the problem.
> >
> >
> >
> >
> >
> > --- In domaindrivendesign <at> yahoogroups.com, Nuno Lopes nbplopes <at> wrote:
> > >
> > > There is nothing wrong with it. But in in some situations one may
> benefit
> > > from a "domain model", especially regarding the message (templates
> etc etc).
> > > Just sending is a function.
> > > The problem/question was more if it was good or bad injecting
> services
> > > into the domain object.
> > > I think the sending an email was more of a pretext to fire the
> conversation.
> > >
> > > Nuno
> > >
> > > On Fri, Jul 31, 2009 at 7:35 AM, Udi Dahan
> thesoftwaresimplist <at> wrote:
> > >
> > > >
> > > >
> > > > In the bounded context of sending email, is the domain model
> really
> > > > appropriate?
> > > >
> > > > What's wrong with the simpler transaction script approach,
> especially given
> > > > that we're not really persisting anything?
> > > >
> > > >
> > > >
> > > > -- Udi Dahan
> > > >
> > > >
> > > >
> > > > *From:* domaindrivendesign <at> yahoogroups.com [mailto:
> > > > domaindrivendesign <at> yahoogroups.com] *On Behalf Of *Jesper De
> Temmerman
> > > > *Sent:* Friday, July 31, 2009 9:07 AM
> > > > *To:* domaindrivendesign <at> yahoogroups.com
> > > > *Subject:* Re: [domaindrivendesign] Re: Designing a content
> management
> > > > system
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > So instead of:
> > > > >
> > > > > public class Message {
> > > > > public void send() {
> > > > > emailService.sendEmail( ... );
> > > > > }
> > > > > EmailService emailService;
> > > > > voic setEmailService(EmailService emailService) { ... }
> > > > > }
> > > > >
> > > > > you recommend:
> > > > >
> > > > > public class Message {
> > > > > public void send(EmailService emailservice) {
> > > > > emailService.sendEmail( ... );
> > > > > }
> > > > > }
> > > >
> > > > (I don't like the Service name, it reminds me of service layer
> classes. I'd
> > > > call this an EmailSender)
> > > >
> > > > > Among the things I don't like about this;
> > > > > 1. you've now exposed details about how a Message's send()
> method is
> > > > > implemented to the caller (ie it needs an EmailService)
> > > >
> > > > No matter what you do, you'll expose those details because
> fundamentally,
> > > > you need a way to set that EmailService. If you use some private
> field
> > > > reflection trick for this you're even doing more harm because:
> > > > a) the requirement on the message class it is not evident from the
> > > > interface of that class anymore.
> > > > b) your message class cannot change its internal (hidden) state:
> you break
> > > > reflection by changing that field name.
> > > > c) you _cannot_ reuse your message without documenting that there
> is an
> > > > internal private variable named emailService that you need to set.
> > > > d) you cannot change the implementation of the service.
> > > >
> > > > With the send(IEmailSender sender) code you're calling a send and
> you know
> > > > that it is sent via the supplied sender. If you want to use it,
> you HAVE to
> > > > supply a sender.
> > > >
> > > > > 2. you've made it the responsibility of the caller to have to
> provide
> > > > this
> > > > > EmailService
> > > >
> > > > Agreed, but I don't really see anything wrong with that. Why would
> the
> > > > caller create a message and not know how to send it? And even if
> the caller
> > > > does not know where to get an EmailSender, there could be a
> service locator
> > > > that does now. This keeps your responsibilities nice and separate
> too.
> > > >
> > > > > 3. passing in the service as a parameter seems like false
> scoping: it
> > > > > suggests that the service may vary on an
> invocation-by-invocation basis,
> > > > > whereas in practice it will not
> > > >
> > > > It won't - in a lot of applications at least. But during the
> lifetime of
> > > > your application it surely can. If you interface via an
> IEmailSender, the
> > > > details of that sender can vary. Maybe your sender wants to
> support a new
> > > > SMTP protocol? Maybe you actually want to use different senders
> depending on
> > > > where the mail is going (mail to employees = bypass spam filter,
> mail to
> > > > external = run virus scan)?
> > > >
> > > >
> > > >
> > > >
> > >
> >
>



__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 4 comments |
headers
nichols_mike_s | 3 Aug 15:23
Picon
Favicon

Reporting Context considerations

I have a object that I have identified as an Aggregate Root called 'FracturedFacesTest'. It represents a
materials test done in a laboratory.
Within a Testing Bounded Context, some property values are set. The FracturedFacesTest has some
algorithms that are done to derive other properties. 
These derived/calculated properties are NOT used anywhere throughout the rest of the Testing context .

Ultimately, however, these properties would need to be _reported_ to the end user...probably in a web
page. 
What I am not sure of is whether I should move the properties and the algorithms to the Reporting Context
since as I mentioned they are not consumed in the testing context. 

The calculations _feel_ more natural within a testing context since this is what a materials test
does...the derivation of properties related to a material by various operations. But the only usage of
these properties would be perhaps writing to persistence for consumption within a Reporting Context. 

Would you tear the algorithms into the Reporting Context representation of FracturedFacesTest ? This
would have the side-effect of leaving the original entity anemic but its identity is still important
within the system in other concerns.

------------------------------------
Permalink | Reply | 3 comments |
headers
Pat Maddox | 3 Aug 19:06
Picon

Re: Reporting Context considerations

Those calculations are domain logic, so should go in the model.
Publish the results and let your reporting context pull them in.

Pat

On Mon, Aug 3, 2009 at 6:23 AM, nichols_mike_s<nichols_mike_s <at> yahoo.com> wrote:
> I have a object that I have identified as an Aggregate Root called 'FracturedFacesTest'. It represents a
materials test done in a laboratory.
> Within a Testing Bounded Context, some property values are set. The FracturedFacesTest has some
algorithms that are done to derive other properties.
> These derived/calculated properties are NOT used anywhere throughout the rest of the Testing context .
>
> Ultimately, however, these properties would need to be _reported_ to the end user...probably in a web page.
> What I am not sure of is whether I should move the properties and the algorithms to the Reporting Context
since as I mentioned they are not consumed in the testing context.
>
> The calculations _feel_ more natural within a testing context since this is what a materials test
does...the derivation of properties related to a material by various operations. But the only usage of
these properties would be perhaps writing to persistence for consumption within a Reporting Context.
>
> Would you tear the algorithms into the Reporting Context representation of FracturedFacesTest ? This
would have the side-effect of leaving the original entity anemic but its identity is still important
within the system in other concerns.
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

------------------------------------
Permalink | Reply | 2 comments |
headers
nichols_mike_s | 3 Aug 19:52
Picon
Favicon

Re: Reporting Context considerations

@Pat
Thanks for your reply.

Is it commonly held to keep models in a reporting context as dumb as possible then? At first I thought so but as
I looked at the behavior of my FracturedFacesTest I realized that the calculations are primary concerns
of reporting, not testing, so I wondered if others have made their Reporting models more behavioral than
simple getters.

--- In domaindrivendesign <at> yahoogroups.com, Pat Maddox <pat.maddox@...> wrote:
>
> Those calculations are domain logic, so should go in the model.
> Publish the results and let your reporting context pull them in.
> 
> Pat
> 
> On Mon, Aug 3, 2009 at 6:23 AM, nichols_mike_s<nichols_mike_s@...> wrote:
> > I have a object that I have identified as an Aggregate Root called 'FracturedFacesTest'. It represents a
materials test done in a laboratory.
> > Within a Testing Bounded Context, some property values are set. The FracturedFacesTest has some
algorithms that are done to derive other properties.
> > These derived/calculated properties are NOT used anywhere throughout the rest of the Testing context .
> >
> > Ultimately, however, these properties would need to be _reported_ to the end user...probably in a web page.
> > What I am not sure of is whether I should move the properties and the algorithms to the Reporting Context
since as I mentioned they are not consumed in the testing context.
> >
> > The calculations _feel_ more natural within a testing context since this is what a materials test
does...the derivation of properties related to a material by various operations. But the only usage of
these properties would be perhaps writing to persistence for consumption within a Reporting Context.
> >
> > Would you tear the algorithms into the Reporting Context representation of FracturedFacesTest ? This
would have the side-effect of leaving the original entity anemic but its identity is still important
within the system in other concerns.
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

------------------------------------
Permalink | Reply | 1 comment |
headers
jlembke | 3 Aug 21:15
Picon

Re: How do I handle data that needs to be interpreted?

Core numbers are a part of the domain, but the definitions for them live in another system (AS400
invoicing). We don't want to move that data to our new DB system because then we would have to manage those
numbers in two places. The new system manages return requests, which need to reference those numbers.
When the user inputs a request, all they have available is the part number, yet the $ for returns is based on
the core. Several parts may share the same core number.

So, we allow users to enter part numbers, and then we translate that part number to a core number by going to
the invoicing system. Once we have the core number, we no longer care about the part number.

So how do I regard the need to do this translation?

--- In domaindrivendesign <at> yahoogroups.com, Kurt Häusler <kurt.haeusler@...> wrote:
>
> Should "Core Number" not already be part of the "Core" entity? Or are we
> talking about creating new Cores here? If the latter, where do core
> numbers usually come from, in domain terms?
> 
> "get the appropriate core information from a database" sounds like you
> are either getting this information from outside your domain, or you are
> mixing some data centric design in there.
> 
> Do you have a db table just for mapping part numbers to core numbers? If
> so I would look at moving them into the domain if possible, otherwise as
> last resort a separate db lookup could work. Now if this is some
> external system, i.e. a different database to where your domain is
> persisted, say some public third party service, then this could be
> encapsulated as domain logic, call it a service if you like, and called
> from within the domain. The other option would be to create a separate
> repository just for this bit of data, and treat it as an aggregate, but
> this smells like it should just be part of the core entity in the first
> place.
> 
> 
> 
> jlembke wrote:
> > Not sure how to forumulate that question, so here's the situation:
> > 
> > My Aggregate contains a list of what are called "cores". (if you've ever bought an automotive *part* you
frequently pay a "core charge" which is similar to a deposit. A used automotive part is referred to as a
core, and can in some cases be returned to get the deposit back.
> > 
> > Core numbers and part numbers are different. And my Domain Aggregate must deal with core numbers. The
problem is, users don't know core numbers, just part numbers. So before I can work with my domain
Aggregate, I have to take the Part number input by the user, and get the appropriate core information from a database.
> > 
> > The question is, how do I handle getting the Core number, which I need to do in order to build my Domain
Aggregate? Do I just use a service to one-off that bit of needed knowledge and hit the database outside all
my repositories? what is a clean way to do this?
> > 
> >
>

------------------------------------
Permalink | Reply | 1 comment |

Gmane