<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.programming.domain-driven-design">
    <title>gmane.comp.programming.domain-driven-design</title>
    <link>http://blog.gmane.org/gmane.comp.programming.domain-driven-design</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22364"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22358"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22344"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22343"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22341"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22340"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22338"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22337"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22333"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22329"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22326"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22322"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22321"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22316"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22307"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22294"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22293"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22276"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22272"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22271"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22364">
    <title>Questions : Relation between SOA, Domain Service, Repositories and Entities</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22364</link>
    <description>&lt;pre&gt;Recently I joined a new company which is a travel company, they have an old asp system. I have been asked to develop a .net application to replace the old asp system. which I come across try to use DDD. This is the first time I am implementing apps using DDD.

I have read the book of Jimmy Nilsson "Applying Domain Driven Design and Patterns". I also downloaded the sample C# program about the cargo tracking. It really confused me about the relation between application services (SOA ??), Domain Service (Services in Eric Evan[DDD]), repositories and entities. I have the following question to ask(hopefully you guys can help me because I don't have a person to ask these questions):

1. Should the entity knows about the repositories? To do CRUD operations?

2 What is the domain services, first i thought they should handle domain business logic and algorithm. But it seem that from Jimmy's book the domain service can do CRUD operations as well. And also Entities can refer it as well. 

3 if entities that know about repositories and domain services, is that kind of messed up the entities as a object itself? 

4 From the sample cargo project, should application service knows about repositories? Is that kind cross layer reference?

5 where should the transaction be handled in the application service layer? 

Those question keep confuse me. I tried to ask some developers, but seems everyone has a different idea.

Hopefully you guys can help me with those questions

Thanks a lot.



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

&lt;/pre&gt;</description>
    <dc:creator>tiger_lu_hao</dc:creator>
    <dc:date>2012-05-22T01:51:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22358">
    <title>Calendar with recurring events</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22358</link>
    <description>&lt;pre&gt;Hi all, 

I know this has been discussed around two years ago but I am looking for a concrete solution with recurring events involving complex time rules: daily, weekly, monthly. MS Outlook has a great deductive UI that helps to understand those rules. It will take place in a shared calendar and high volume. As Vaughn said in that previous thread the queries are really complex and I don't find any solution that involves just a query. Having in mind that we store the recurring event (and not the occurrences because of performance reasons) I see a potential solution similar to the one described by Martin Fowler in its Recurring document and doing in memory calculations based on the time expressions of each event.

Any help is appreciated.

Thanks,
Sebastian



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

&lt;/pre&gt;</description>
    <dc:creator>sebaszipp</dc:creator>
    <dc:date>2012-05-21T13:35:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22344">
    <title>The Economics of Reuse: DDD vs SOA</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22344</link>
    <description>&lt;pre&gt;Is DDD bound to a "Silo" approach, as opposed to SOA's "Peer to Peer" philosophy.
http://caminao.wordpress.com/engineering/system-engineering-processes/reuse/



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

&lt;/pre&gt;</description>
    <dc:creator>remyfannader</dc:creator>
    <dc:date>2012-05-20T04:24:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22343">
    <title>The 4th Annual DDD eXchange // Join us on June 15th!</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22343</link>
    <description>&lt;pre&gt;Skills Matter is pleased to announce the 4th DDD eXchange taking place on June 15th! The annual conference brings together leading experts with 125 practitioners and enthusiasts for an interactive, high energy event.  Join us to learn and share with the leading designers and developers in DDD. The conference will be led by Eric Evans who will be speaking on 'Strategic Design and Established Formalisms'. Other highlights include Greg Young on 'Functional Programming with DDD', and Hans Dockter on 'Gradle and the Domain Model.' Don't miss the DDD exchange this June 15th, a truly established date in the DDD calendar. Read the full programme here!

What: DDD eXchange 
When: 15th June 2012
Wherre: Skills Matter, 116-120 Goswell Road, London, EC1V 7DP
Twitter: #dddx
Full Programme and tickets: http://bit.ly/DDDX2012



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

&lt;/pre&gt;</description>
    <dc:creator>Skills</dc:creator>
    <dc:date>2012-05-17T10:50:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22341">
    <title>Defining  Associations</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22341</link>
    <description>&lt;pre&gt;Hello All,

I wanted to ask the community about their thoughts regarding the preferred strategy on defining associations in a model.
In my understanding, if an Aggregate Root is being defined then any domain associations need to defined and accessed only from within the Aggregate Root, so that the invariant it is maintaining can be satisfied.

But what if the model component is an Entity and not an Aggregate Root and there is no invariant to be maintained would it make sense to define in the model any associations that may exist in the domain based solely on the argument that they are present in the domain?
It is very often the case that too many associations are defined upfront without us really being able to explain the benefit that those associations bring (apart from facilitating UI rendering).

Any thoughts?

Cheers,
Savvas



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

&lt;/pre&gt;</description>
    <dc:creator>savvas_andreas_moysidis</dc:creator>
    <dc:date>2012-05-10T17:00:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22340">
    <title>Beyond Layers: DDD and Architectural Styles (Plural)</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22340</link>
    <description>&lt;pre&gt;See you on June 11 &amp;lt; at &amp;gt; #DDD Denver for the discussion:

"Beyond Layers: DDD and Architectural Styles (Plural)"

http://www.meetup.com/ddd-denver/

Vaughn



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

&lt;/pre&gt;</description>
    <dc:creator>vvernon_shiftmethod</dc:creator>
    <dc:date>2012-05-08T05:59:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22338">
    <title>Creating and refactoring identity fields of Entities</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22338</link>
    <description>&lt;pre&gt;We are learning DDD and evaluating its use for a system backed by a legacy system &amp;amp; datastore.

We have been using Anti-Corruption Layer, Bubble Context and Bounded Context without knowing about them, and this approach seems very practical to us.

But we are not certain and confident about identification methods and identity correlation. Legacy data store does not have primary keys, instead uses composite unique indexes to identify information.

We are currently creating our model as Value objects that should be Entities (wishing to add "Long id" field to every one), or we rarely use combination of attributes used in unique indexes as id field. It seems clear to us that Entity models should have id fields.

Here are my concrete questions:

  *   We want our shiny new Entities to have "Long id" fields theoretically. Is it OK not to add that field now since that gives us no value as the backend data store won't fill or understand that field?
  *   Is it OK in DDD way to store identification information and refactoring it sometime later hopefully datastore changes towards our needs.
     *   If so, is abstracting identification from Entities good approach (I mean Identifiable interface, or KeyClass per Entity? - Any good advice is needed here..)
  *   This question may be out of the scope of DDD but i wonder if identification refactoring can cause impacts on several layers of the systems (For example, REST api may change from /entity/id_field/id_field/id_field to /entity/new_long_id)

and other questions :

  *   How can we use the legacy information for our growing polished domain model, with less pain in identification stuff?

  *   Or is it bad and not valuable to wish Long id for our domain at anytime of the project's life?

  *   How can we refactor identity management?


İbrahim Esen
Senior Software Engineer
Anadolu University
ibrahime&amp;lt; at &amp;gt;anadolu.edu.tr&amp;lt;mailto:ibrahime&amp;lt; at &amp;gt;anadolu.edu.tr&amp;gt;
&lt;/pre&gt;</description>
    <dc:creator>İbrahim ESEN</dc:creator>
    <dc:date>2012-04-29T11:07:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22337">
    <title>The cases for reuse</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22337</link>
    <description>&lt;pre&gt;How to deal with objects targeted by different domains.
http://caminao.wordpress.com/2012/04/09/cases4reuse/



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

&lt;/pre&gt;</description>
    <dc:creator>remyfannader</dc:creator>
    <dc:date>2012-04-30T11:20:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22333">
    <title>francais [1 Attachment]</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22333</link>
    <description>&lt;pre&gt;
&lt;/pre&gt;</description>
    <dc:creator>Remy Fannader</dc:creator>
    <dc:date>2012-04-24T09:17:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22329">
    <title>DDD queries</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22329</link>
    <description>&lt;pre&gt;Hi all,

I'm building a new application and am new to DDD. I've been reading through some of the documentation and I've managed to model most of the domain model but I would like some advice about two queries:

1. I have two domain objects channel and program. I've modelled these both as entities as both can be accessed independantly. A channel can have a list of programs so I have put this as an attribute of channel. My query is how should I populate the program list. Is it OK for the getChannerById method in ChannelService to first get the channel information and then call the programService to get the list of programs for the channels e.g: 

Channel {
  String channelId 
  List &amp;lt;Program&amp;gt; programList
} 

Program {
  String programId { 
}

ChannelService {
   Channel getChannelById(String channelId)
}

ProgramService {   
   Program getProgramById(String programId)
   List &amp;lt;Program&amp;gt; getProgramsByChannelById(String channelId)   
}

2. I have a product domain object but some of its attributes (e.g. specification and compatability) involve quite time consuming operations. These attributes are not required all the time so is it OK to put these as part of the domain object and have seperate service methods that populate these properties as required e.g.

Product {
    String productId
    Specification specification
    List &amp;lt;Product&amp;gt; compatibleProducts
}
 
ProductService {
    Product getProduct(String productId);
    void getProductSpecifications(Product product);
    void getCompatibleProducts(Product product);
}

Any advice would be very much appreciated.

Thanks in advance



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

&lt;/pre&gt;</description>
    <dc:creator>Sbhachu</dc:creator>
    <dc:date>2012-04-20T16:59:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22326">
    <title>Need for Diagnostic Methods/Algorithms to Classify Domain Objects</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22326</link>
    <description>&lt;pre&gt;Hello,

First of all, I am aware that building blocks are not the core value of
DDD, but only patterns to keep things clear. Yet I've found them very
useful in many situations. But I still have many doubts when it comes to
classify the domain objects. (as entities, value objects, services,
aggregate roots, ...)

I see people spending a lot of time making these decisions too. There is
some knowledge floating around with variety of different understandings and
this makes the process even more difficult.

I think it would be really helpful if DDD experts could come up with a
diagnostic method (or more formally, an algorithm) (a hierarchical one,
perhaps?) that would help us classify our objects. I know people have been
saying things like "if object has an identity, it is entity" etc. But most
of these statements are ambiguous and they make the situation even more
complex.

I think what we need is a clear method, that consists of some diagnostic
steps to help us, something like:

Entity / Value Object Diagnosis:
1) If an object satisfies X and Y, then it is a V.O.
2) If condition at 1 is not satisfied, then check whether object has Z and
no other object has Z. Then, it is an Entity.
...

PS: I think aggregate root diagnosis is covered much better (by some
extensive documentation) than entity/value object diagnosis.

Thanks,
Ali Cevik.
&lt;/pre&gt;</description>
    <dc:creator>Ali Çevik</dc:creator>
    <dc:date>2012-04-19T21:17:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22322">
    <title>DDD and Spring Security 3.1</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22322</link>
    <description>&lt;pre&gt;Hi, this is my first post in this group.

I'm building an app with Spring/Spring-MVC/Spring-Security 3.1. I'm  reading all that I can about DDD (bought the book). Also, I'm taking some lessons from http://dddsample.sourceforge.net/

The thing is, I have to implement a SS's CustomUserDetailsService (for custom authentication). The first obstacle is that I don't know in which layer I have to put this object. My first guess was the infrastructure layer but the thing is that the service knows about interfaces/objects from the domain layer and I thought domain layer had to use infrastructure layer and not the other way around. So I thought about the application layer, but that smells for other reasons.

Any thoughts? Someone with this kind of experience?

Thanks in advance.



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

&lt;/pre&gt;</description>
    <dc:creator>tomasix</dc:creator>
    <dc:date>2012-04-17T15:15:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22321">
    <title>DDD in Flow3</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22321</link>
    <description>&lt;pre&gt;Hello,

i got a question about DDD in Flow3.
The Manual on http://flow3.typo3.org/documentation/guide/partii/modeling.html says in the section about Aggregates:

"If you want to display comments independently from their posts and blogs, you'd surely need a Comment Repository, too"

If i'd like to use a Comment Repository, will the model Comment still be inside the Aggregate?

Thanks,



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

&lt;/pre&gt;</description>
    <dc:creator>johannes.steu</dc:creator>
    <dc:date>2012-04-08T10:36:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22316">
    <title>DDD and Acord within the insurance domain.</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22316</link>
    <description>&lt;pre&gt;Hi Guys,

This isn't so much about DDD specifically but rather around how frameworks
such as Acord can be utilised with DDD applications.

My knowledge of Acord is very limited but from what I've seen so far it is
a Information Framework with lots of xml/edi schemas etc.  And it therefore
sits at the [web] service layer and can in part define interaction between
various systems.

I would be interested in hearing peoples thoughts and experiences on Acord
and DDD.

How applicable is the use of Acords "Business Glossary" [1] within DDD
projects.  My belief is that it is more of a context map than something
that can be used as the domain itself.  For me this is driven home by the
fact that Acord talks to data models as opposed to domain models.

I realise that this is a rather generic and open ended email,  but
hopefully something good comes out of it.  If you have experience with
other Frameworks like TMF SID (and DDD) I would also be very interested in
hearing about them.

The driver for this email came out of a conversation with my PM.  It seems
that we are in the very early stages of getting more insurance work and I
was attempting to dig more information out of my PM as to the scope of
work.  One one issue that my PM and I have is a lack of
a ubiquitous language and I would very much like to be able to explain the
differences to him between DDD and frameworks like Acord.    Sadly I have
seen a previous project from us in which we implemented a DDD (whether that
was the intention or not is uncertain) project in which the domain was
modelled after SID.  It had very little logic within the domain and instead
used Manager transaction scripts to provide the business/billing logic.  I
am really hoping to be able to avoid repeating the same mistakes within
this new project.

Thanks,  I look forward to your replies.

Alistair.


[1] The Business Glossary contains standardized definitions of insurance
concepts, such as “accident location”, and includes synonyms, business
line-specific usage, and references.

The Business Glossary’s consistent terminology will help improve
communication between partners and within project teams.

http://www.acord.org/resources/framework/Pages/default.aspx
&lt;/pre&gt;</description>
    <dc:creator>Alistair Bush</dc:creator>
    <dc:date>2012-03-21T00:52:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22307">
    <title>Doubts when refactoring towards BCs</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22307</link>
    <description>&lt;pre&gt;My first post!

I'm currently trying to apply DDD concepts in a Ruby on Rails application I'm working on that is growing fast. We are applying some of the concepts but we want to advance to the next level, identifying BCs and make a code refactor that reflects them explicitly by splitting the  model, and maybe at some point, upgrade them to autonomous applications. The main objective is increasing model clarity.

So I have some doubts when having this situation: 2 entities, each in a different bounded context, sharing the same identity.

1) Is it correct to say in this case that I have 2 entities? Or it's better to say that I have one entity with 2 different representations in each BC?

2) Their life cycles aren't necessarily the same, right?

For example, if I delete one of the entities in one of the bounded contexts it'd mean that its representation in that context no longer makes sense. 

3) I'm thinking that the smallest refactor I could make towards BCs is choosing some entity and splitting it in 2 to map it to another BC and make it grow slowly and iteratively. Do you have some better recommendation on how to refactor towards BCs?




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

&lt;/pre&gt;</description>
    <dc:creator>daniel_cadenas_nion</dc:creator>
    <dc:date>2012-03-14T05:55:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22294">
    <title>User interaction during a business process</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22294</link>
    <description>&lt;pre&gt;Greetings groupies

Consider the following business scenario of a data updating and versioning system, describing the process of loading a new file version into the versions catalog:
1. The user selects the CSCI id, a version number and browses for a file path.
2. The system checks the format of the specified file.
2.1 If the file's format is not compatible *the user is asked whether to upload the file anyway*.
2.1.1 If the user chooses not to upload the file, the process terminates.
2.1.2 If the user chooses to upload the file anyway, skip to 3.
3. The file is uploaded and saved in the catalog.

Two issues arise here:
1.  Checking the file format compatibility is done via an external service, implemented outside of the domain model. When a part of the process, which is defined by the domain experts as a single process has some logic which is executed on an external service, it cannot be modeled entirely in the domain model. This makes us implement some domain logic in an application layer service in order to coordinate the domain model with the external service.

2. User interaction is required during the process. Can this process be implemented neatly in a single service call, or should one split it into two requests? (e.g. first check for compatibility and then upload). I think that breaking the process into two steps initiated by the user causes logic to leak into the presentation layer (even worse than application service logic).

Would be happy to hear your solutions and/or thoughts about these issues.

Thanks,
Moran



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

&lt;/pre&gt;</description>
    <dc:creator>moranlf</dc:creator>
    <dc:date>2012-03-13T09:48:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22293">
    <title>Looking for a Decent Way to Track Who Performed a Query on the Reporting Databas</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22293</link>
    <description>&lt;pre&gt;Hey all,

I'm looking for some ideas on the following potential scenario:
* User queries and gets a detail view for a Product through the Reporting Database
* The said User seeing that view needs to be persisted to the Product activity log view as an event
* The Product activity log view contains all Product related events raised from the Product aggregate.

From what I've been seeing, the Reporting Database is very thin and pure; it just lets you queries for read data. Where does it make sense to track that the User got a detail view and publish the event to the handler that writes to the Product activity log?

Regards,

Tony





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

&lt;/pre&gt;</description>
    <dc:creator>badcompany16&lt; at &gt;yahoo.com</dc:creator>
    <dc:date>2012-03-13T02:59:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22276">
    <title>DDD and the database</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22276</link>
    <description>&lt;pre&gt;Hi,

I have been given the importunity to architect my first system.
The review from the three more experienced architects in my company has not gone well, they are not happy with my architecture.

The major problem is this. Within my application, the database belong exclusivity to the application. The application will be deployed to a very large number of clients. These clients don't care about how the data is stored or where, about the database and will never write any applications of themselves on the database. Even reporting is done within the realms of my application; however the reporting is done from a database which is separate from the OLTP database.

From the criteria above, I have thus come to the conclusion that the entities and value-objects in the Domain of the application is the same as the database. I thus use nhibernate, with the help of fluent hibernate, to map the domain objects to a database. It works out pretty well; the database is in 4th normal form, clean and very understandable. I understand that relinquishing the power of creating the database separate from the domain allow for more advanced normalizing which means better performance. However, with my system, these possible performance problems are acceptable with the trade off against having such a clean and database. The irony is, when looking at the database created by nhibernate, is better than what I would have come up with in any case...

Off course, I still use all of the patterns within DDD, such as repositories which separate the physical database from within the domain environment.

The architects who reviewed my system is however adamant that I must not generate the database from the domain. I must create the database by hand and then write the hbm xml mappings to map the domain objects to the database.

My question is, is this really necessary in an application where the domain dictate what the database looks like? Thus in other words, the database purely exists to persist the domain and the database will never be used for any other system Am I missing something?

Thanks for all the help in advance.




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

&lt;/pre&gt;</description>
    <dc:creator>alvl1973</dc:creator>
    <dc:date>2012-03-10T17:09:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22272">
    <title>I like my sherry DRY ... but what about my validations?</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22272</link>
    <description>&lt;pre&gt;As promised, I'm starting a new thread here to discuss DRY and validation (which should be interpreted rather broadly).

Dan's most excellent articles about DRY are an excellent starting point to put things in perspective.
http://dearjunior.blogspot.com/2012/03/dry-is-about-ideas-not-text.html
http://dearjunior.blogspot.com/2012/03/dry-and-duplicated-code.html

So, the doctor asks: what's the problem?

Recently I've had some discussion with colleagues and some deep reflective thoughts with myself about keeping validation logic DRY. Validation comes in all shapes and sizes. There's the kind in the UI that enhances the UX, which mostly revolves around disabling things you can't do, notifying you as an end-user that the data you entered is invalid, or steering UI input controls with constraints such as maximum lengths, requiredness, between ranges, etc ... Notice how most of these things revolve around knowing metadata and the state "data" is in. Next to all that could be a service layer or command handler of some kind (CQRS-ish) that accepts DTOs/Commands from clients (UI or other). Again, you're trying to be a good citizen and not let calls with "invalid data" enter the domain. What I've 
 personally been doing in this space is writing request validators, which I stuff into the processing pipeline of a service operation handler or command handler. Most of the time these validation failures are explicit (well described, translatable) when it comes to indicating what's wrong to the client. And then finally we arrive at the domain model, with its aggregates, value types and entities. One school of thought is "we need to protect the domain model no matter what!". Contrast this with "well I already validated this in the layer above, which will never be bypassed, so why bother?". I see virtue in protecting the domain model if the code is going to be hosted behind several facades, less so if that facade is going to be the same command handler/service operation handler. Yet I do h
 ave to acknowledge that if the same value type is constructed in many handlers we're basically trusting validation to have happened beforehand (possibly repeated or centralized in some DTO "to be mapped onto a value type" validator) and that could be seen as a problem by the "protecting the domain no matter what" camp.

As you can read, there's some duplication going on here, for different reasons.

DISCUSS!



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

&lt;/pre&gt;</description>
    <dc:creator>yves.reynhout</dc:creator>
    <dc:date>2012-03-08T19:57:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22271">
    <title>Requirements capture</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22271</link>
    <description>&lt;pre&gt;Using the Gof4 distinction between creational, structural, and
behavioral patterns for requirements capture.
http://caminao.wordpress.com/2012/03/01/requirements-strokes/
&amp;lt;http://caminao.wordpress.com/2012/03/01/requirements-strokes/&amp;gt;
Remy Fannader

&lt;/pre&gt;</description>
    <dc:creator>remyfannader</dc:creator>
    <dc:date>2012-03-01T14:43:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22268">
    <title>We never talk about analysis any more</title>
    <link>http://comments.gmane.org/gmane.comp.programming.domain-driven-design/22268</link>
    <description>&lt;pre&gt;I was doing a run by posting of a game I like to play with domain experts.
Figured it might spark conversations on other games

http://goodenoughsoftware.net/2012/02/28/the-gibberish-game/

&lt;/pre&gt;</description>
    <dc:creator>Greg Young</dc:creator>
    <dc:date>2012-02-28T15:17:27</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.programming.domain-driven-design">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.programming.domain-driven-design</link>
  </textinput>
</rdf:RDF>

