Design help

Hi group,

I need some help how to model the following problem:

The application I want to model is a web application. The application provides news items on an URL. A
business rule is that the user can only get a news item once. The first time the user requests the URL the news
item is returned. However, every next time the news item will not returned. A marker is put in the cookie
object if a news item has returned so the next time the news item is not returned.

The basic objects are easy to find, but the most difficult for me is where to put the Request, Response and
Cookie objects. Are these domain objects and must they include in the domain? If placed in the domain the
application is restricted to web clients as Request, Response and Cookie are pure web concepts. If
Request, Reponse and Cookie objects are part of the domain you cannot make the application accessible for
other types of clients (maybe standalone clients).

Could anyone please help me with this issue?

Kind regards,
dee.

------------------------------------

Aggregate Root: Consistency boundaries for transactions

Hello,

The architectural context here is event sourcing, CQS, and SOA.

So if aggregate roots form consistency boundaries for transactions...

Am I correct in thinking that aggregate roots and services (SOA services) are the same with respect to
transactions? In other words, just as transactions between services (distributed transactions) are a
bad thing the same is true for aggregate roots?

Thanks

------------------------------------

Presentation Models

Application layer without domain logic?

Hi all,

I am currently planning a new billing system for one of our customers.  A few operational systems are going to
user the billing system as a service. When booking a transaction, the operational system must pass the
customer account (an identifier) to be billed, a product (an identifier) and a few more infos. The product
price is based on the customer account and the product so it can be fetched internally.

Now so far I planned to have the following entities:
- Customer Account
- Product
- Price List
- Accounting Record

When booking a transaction a customer account will be debitted. But there can be several cases, that when an
operational system is booking a transaction there is no customer account because the wrong identifier
might have been provided. In this case the transaction needs to be marked as invalid, needs to be stored and
later on repaired by one of the employees by providing the correct information (like an existing customer).

The decisions whether to create and store an invalid transaction record or to store a valid accounting
record are, from my point of view domain logic.

So I was thinking about creating a service that will take care of the above issues like:

BookTransaction(customerId, productId, ...)
{
   customer = repository.find(customerId);
   product = repository.find(productId);
   if(customer == null || product == null)
     // store as invalid transaction
   else
     // store accounting record
}

Now my question is if it is correct to have a service that books transactions and decides whether a
transaction is valid or not and takes the appropriate actions? Would this service be an application or a
domain service (in the same a assembly as the domain model)? 

Thanks in advance,
Chris

------------------------------------

Does CQS Break Down the Ubiqutous Language?

I was listening to Greg Young on Herding Code and much of what he was saying made perfect sense and stroked my
developer instinct in exactly the right way.  Of course applications shouldn't be just CRUD and of course
it is the behaviors that matter!

One question that I have comes up when Greg talked about avoiding getters and setters in your domain
entities.  I have heard this refrain before and now I feel like I am starting to grasp the reasoning behind
it.  One related thing that he mentioned - and Greg, I know you read this so correct me if I'm wrong - is that it
usually makes more sense to project your display data directly to DTOs rather than having a domain
middle-layer get involved.  

Again, this makes sense but I wonder if it doesn't start to break down the ubiquitous language somewhat?  For
example, when your domain experts discuss a Customer they don't only talk about adding a valid address
which validates against their listed zip code, they talk about being able to check the customer's address
as well!  If you don't have an address getter on the customer, then it seems like when your domain expert says
something like "at this point the customer address should be xyz" you will no longer have a 1-to-1
correspondence between the language and your domain.

Can someone clarify how this is supposed to work? 

------------------------------------

Technical requirements for CQS/Event Sourcing/Eager Read Derivation

Hi all,

I'm just wondering what thoughts people have on the minimum tech specs  
to achieve some of the features of the Event Sourcing model,  
especially the storing of explicit state transitions (events).

We're currently deploying a version of our app on Azure, which is  
still in early days and doesn't have, as yet, as many features as we'd  
like from a cloud platform, but that's where we're at. It does have  
BigTable-like storage (Azure Table Storage) and a basic message queue  
(not guaranteed to be FIFO) and blob storage, but there's no  
distributed caching for example.

So here are some issues we're thinking about:

* How can we store our event stream in a manner that's performant?

   - When we process commands, we need to build up our aggregates, so  
we'll need to read all events up until the last snapshot - how can we  
construct optimised queries for this given the limitations of the  
storage and query language? And is there a way to avoid doing this for  
every new command we need to process?

   - We could try caching aggregates in memory on the worker nodes,  
but given that nodes are homogeneous, there's no (straightforward) way  
to ensure the workers will retrieve command messages off the queue for  
the aggregates they're caching. As there's no distributed in-memory  
caching capabilities, the only other option would be to try to use the  
blob storage as a cache, which would still be writing/reading from disk.

* How can we "ensure that our audit is correct"?

   - This is one of the touted features of state transition storing  
and sourcing, but if the events are just stored in an open table  
format, then what's to stop them being modified (as long as they're  
modified within your validation constraints)? Do we need to store a  
checksum along with a server-side secret, or something like that, for  
each event?

* How can we construct our read layer to apply event changes?

   - Again, given homogeneous worker roles, how do we coordinate the  
reading of the event storage so that events are only applied once - do  
we need to keep a whole lot of versioning information in the read  
layer as well? And generally how does each worker node know where to  
start reading from in the event storage?

Now, I'm not actually expecting answers to these questions themselves,  
but more broadly just interested in what people's thoughts are on the  
necessary features that you need in a system to support this design.

Can CQS/Event Sourcing only be achieved in certain environments, and  
if so, what sort of features do you need?

Cheers,

Michael

------------------------------------

ORM tools and various design approaches - how do they fit?

Good day!

I am a student and I am doing a study on ORM tools and how they fit into various software design patterns and
approaches. For now I have tried some tools and read about their weaknesses and strengths related to MVC
and n-tier design patterns and also have an experience with some projects. But lately I have found out
about those concepts: data-driven design (is it the same as data-driven architecture or those are two
different things?), domain-driven design, model-driven design. And I got a bit confused how does this
all fit together with ORM and what is ORM role in those designs.

There are tools like Hibernate which allow users to create mappings and classes as they wish. I have seen a
project where developers create almost 1:1 mapping (except some business object related properties)
for almost each database table and use entity classes only as a new datatypes without implementing any
functionality in them. All the basic CRUD functionality and business logic in that particular project is
implemented  in a „business object factory" layer. I guess it is not the best way of using object-oriented
design because our business objects are really just some "property bags", but still – what design model
it is then; how do you call it? I guess it could be based on model-driven because we used electronic
implementations of various physical paper documents and their relationships as a basic building elements.

In the project we tried two technologies. The first was NHibernate. We ended up with creating many similar
entities, similar business object factory classes and similar web services – it was a big
"copy-paste-rename-customize BOF classes to fit the particular document operations" work but we were
lucky that NHIbernate allows to treat all the entities the same way – dynamic filtering methods which can
be used for any entity were so simple to write and use. We tried LINQToSQL and Entity framework. The good
part was - LINQToSQL and Entity framework generate partial classes with invisible CRUD mechanisms and
offer ability to extend classes and embed some business logic – I guess this would be more close to OO
principles then our "property classes". But it was really hard to create some generic operations with
entities, especially universal filtering. So we stayed with NHibernate. Also in our project we used
SharePoint and Infopath "because the client said so". Infopath forms need strict data definitions with
XML schemas and they are really hard to develop and debug if you try to put some more code than data
validation (I guess it would be completely wrong design to put some business logic into Infopath form). 
As I understand, data-driven architecture means that instead of creating many web services/UIs for each
kind of our entities, we create some more or less "universal" services and UIs and then create some data
model to tell our services and UIs what kind of entity we are working on. As the Infoapth needs strict data
sources we could not develop them "data-driven" way – we would spend too much time trying to create
universal Infopath form and universal web service to reuse it for many kinds of our entities. I wonder if
this problem is one if the reasons why „data-driven architecture" has been called a not-so-good idea
lately (especially when developing for SOA)? So we continued to "copy-paste-rename-customize" for
Infopath forms and web-services. 

There are „active-records" kind of ORM tools, where entities have CRUD embedded inside.  Does it mean that
the right way would be to go even further and implement also some business logic into those entities and
only after that try to tune the actual mapping to get our business entities to persist somewhere? 

And finally I got to domain-driven design. How ORM tools fit in there? And how should a good OR/M tool behave
itself in domain-driven design? 

Where is the point when domain-driven design connects with entity model and ORM and how should we work if we
are forced (by client) to use some technology which has some limitations?

Uhh, I have written so many questions. But I just could not find any literature where ORM tools are explained
in context of various design approaches and how to use ORM tools the right way to follow good OO design. And
more important – if domain-driven design is "so cool thing" then what would be the most appropriate way
for an ORM tool to be implemented to fit DDD (would be really nice to see some practical examples and
analysis like – "this tool does not fit because …; this tool would fit if only …")? 

If you could suggest some literature I would be grateful.

Thanks.
Martin.

------------------------------------

QI4(N?)

Not sure if Roger or Rickard were going to post this, but I just ran  
across it and thought others may be interested too:

http://rogeralsing.com/2009/06/25/composite-oriented-programming-qi4j-running-on-net/

Looking forward to seeing how this progresses Roger!

Cheers,

Michael

------------------------------------

assumptions of anti-corruption layer approach?

hi,

i can see how the idea of A.L. might work when a new feature is very
on-the-side compared to old crufty code.

i don't grok how one can add a new 'feature' into an old crufty system
via A.L. when the feature is a refinement of some part of the internal
state of the old code. does one break the old code into 2, before vs.
after the 'new feature', and insert the new feature in-between? or
something?

thanks for any musings.

------------------------------------

(unknown)

Some people have asked me for a link to a presentation on CQS etc. My
QCon talk is now available
http://www.infoq.com/presentations/greg-young-unshackle-qcon08 from SF
08.

Greg

--

-- 
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

------------------------------------

Aggregate root modeling

I have a question about modeling aggregate roots.

Suppose I have a few classes : ContactInfo, Address, Phone, Country, CountryRegion.

I have so far modeled it to the following roots : 

ContactInfo
  Address (has Country and CountryRegion objects)
  Phone

Country
   (has CountryRegion object)

CountryRegion

It seems since ContactInfo holds a CountryRegion object, CountryRegion  must be its own root.  But this
seems weird to me as CountryRegion  means nothing without Country.  Ideally CountryRegion  would be under
Country, establishing 2 roots - ContactInfo and Country.  But I will not be able to access CountryRegion 
under Country, per DDD rules of only going through the root.

Anybody have better ways to model this?

Thanks.

------------------------------------