gmane.comp.programming.domain-driven-design

The 4th Annual DDD eXchange // Join us on June 15th!

Skills — 2012-05-17T10:50:27

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



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

Re: Defining Associations

sweetlandj — 2012-05-12T01:03:36

Savvas,

A relationship may exist in the model but not be realized in code, which is perfectly acceptable.  The model manifests in several forms: the domain-specific language; box-and-line diagrams; UML; text documentation, code, and many others.  It may be helpful to acknowledge and be mindful of such relationships when discussing the model with domain experts.  However, if the relationships are not needed to satisfy business rules in the code, then chances are adding it will only introduce unnecessary complexity.

Often I find that copying the data from one aggregate to another serves just as well and offers many advantages over inter-aggregate references and keeps the code simpler.  The use of events and dedicated read stores also helps avoid extraneous relationships, since it empowers the various applications to construct and maintain their own relationships apart from the core business logic.

Regards,

Jesse


--- In domaindrivendesign< at >yahoogroups.com, "savvas_andreas_moysidis" <savvas.andreas.moysidis

Defining Associations

savvas_andreas_moysidis — 2012-05-10T17:00:31

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



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

Beyond Layers: DDD and Architectural Styles (Plural)

vvernon_shiftmethod — 2012-05-08T05:59:41

See you on June 11 < at > #DDD Denver for the discussion:

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

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

Vaughn



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

Re: Creating and refactoring identity fields of Entities

Jörgen Andersson — 2012-05-02T04:35:07

Hi Ibrahim,

I'll try to answer some of your questions from my experience. Hopefully
others will do the same to offer you a more complete picture to evaluate.

First, entity ids: I don't understand why you want to have Long Id in all
entities or why you see this as the superiour model. I would say the use of
Long Ids is something that the use if ORMs historically have forced upon
us. Then, also, for some some entities there might be no other valid key,
we have to invent one. But in most cases there are already existing
business keys used for the entity, composite or not, and then I always
favour using them.
As a modelling technique I always, regardless the structure of the key, use
a value object as the key, wrapping the Long or the composite key
attributes. This is very conveinient since it provides clear communication
of intent for methods accepting such a key, instead of just a Long. It also
makes it simpler, should the key need refactoring in the future.

Second, separate id storage: Wether it is ids or

Creating and refactoring identity fields of Entities

İbrahim ESEN — 2012-04-29T11:07:07

We are learning DDD and evaluating its use for a system backed by a legacy system & 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 informat

The cases for reuse

remyfannader — 2012-04-30T11:20:35

How to deal with objects targeted by different domains.
http://caminao.wordpress.com/2012/04/09/cases4reuse/



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

Re: francais

Simone Busoli — 2012-04-24T09:22:58

now that's funny

On Tue, Apr 24, 2012 at 11:19, Greg Young <gregoryyoung1< at >gmail.com> wrote:

Re: francais

Remy Fannader — 2012-04-24T09:21:09

Sorry !!!!

On 24 April 2012 12:19, Greg Young <gregoryyoung1< at >gmail.com> wrote:

Re: francais

Greg Young — 2012-04-24T09:19:59

Ouias, j'ai bien compris que tu veux du poulet mais c'est necessaire
d'envoyer ici? :)

On Tue, Apr 24, 2012 at 5:17 AM, Remy Fannader <caminao< at >gmail.com> wrote:

francais [1 Attachment]

Remy Fannader — 2012-04-24T09:17:06

Re: Need for Diagnostic Methods/Algorithms to Classify Domain Objects

vvernon_shiftmethod — 2012-04-23T15:09:14

Yeah, me too ;)

What I have attempted to do is take the recurring sources of confusion across the board, and address them. They may be non-technical and they may be technical. In my experience, the book addresses what most developers run up against. In the case of Value Objects, I spend more than half the chapter (35+ pages total) presenting how do decide in favor of using values and how to deal with each value characteristic while in a modeling effort. Then toward the end of the chapter I spend several pages discussing what to do when the technical realities bump up against your ivory tower.

BTW, since you mention the Whirlpool, remember that you have the option to get things wrong and then address them in a subsequent iteration :) Your best modeling choice today might be quite different from what you would have done with more experience with the domain. Didn't Eric emphasize that the best model will be the one you have at the end of the project? That's pretty much always the case, whether or not we like

Re: Need for Diagnostic Methods/Algorithms to Classify Domain Objects

Ali Çevik — 2012-04-23T14:46:18

Hi,

Peter,
I agree the fact that it all depends on the domain. I think I was not able
to express my problem clearly. So, let's assume I know what I'm
implementing. Still, I have some trouble especially, distinguishing
Entities from Value Objects. And I see a lot of people spending lots of
time classifying their objects to conform DDD patterns. I believe, DDD is a
cloud of meta-domain knowledge, that has evolved in time, abstracted away
from the context by some people who have been working in various domains.
And I am seeking more of this *meta* knowledge. I hope I made my problem
clear this time.

What I'm basically looking for is something like "The Model Exploration
Whirlpool". (Evans,
http://www.domainlanguage.com/ddd/whirlpool/Domain_Language_Model_Exploration_Whirlpool_v2010-06-19.pdf)
Focused at object classification, in a diagnostic manner.

Vaughn,
I am looking forward to your book. But I hope it is not focused too much on
transactions/persistence/concurrency as most of the DDD documents does.

Than

Re: Need for Diagnostic Methods/Algorithms to Classify Domain Objects

vvernon_shiftmethod — 2012-04-22T21:05:12

I agree.

Chapters 5 and 6 of my book, "Implementing Domain-Driven Design," detail several characteristics of Entities and Value Objects. Since Entities are so overused, I provide most of the characteristic analysis to Value Objects, some of which overlap, but this provides more angles to consider as you try to determine the best way to model each object.

Unfortunately, depending on your persistence technology, you may have to compromise and use Entities when a Value Object might otherwise be the natural choice. I also discuss those situations.

The book has been promised for online access on Safari Books Online before long. Stay tuned and I will tweet and post here as soon as the first seven chapters are posted.

Twitter: < at >VaughnVernon

Vaughn


--- In domaindrivendesign< at >yahoogroups.com, Ali Çevik <cevik.ali< at >...> wrote:




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

DDD queries

Sbhachu — 2012-04-20T16:59:22

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 <Program> programList
} 

Program {
  String programId { 
}

ChannelService {
   Channel getChannelById(String channelId)
}

ProgramService {   
   Program getProgramById(String programId)
   List <Program> getProgramsByChannelById(String channelId)   
}

2. I have a product domain object but some of its attributes (e.g. specifica

Re: Need for Diagnostic Methods/Algorithms to Classify Domain Objects

remyfannader — 2012-04-20T04:54:20

Here are clear cut criteria to classify objects.
Identification is the first criterion, combined with context and
life-cycle:

    * Components with local identification and execution (bound to
external active object or actor) and transient life-cycle (end with
session).
    * Components with internal shared execution (simultaneous access by
different sessions) and transient life-cycle.
    * Components with shared execution and persistent life-cycle (object
states must be maintained independently of sessions).
http://caminao.wordpress.com/how-to-implement-symbolic-representations/a\
rchitecture/
<http://caminao.wordpress.com/how-to-implement-symbolic-representations/\
architecture/>

Persistent objects are identified independently of their processing and
can be classified depending on semantics:

    * Representing the state of physical objects.
    * Representing the state of customary (documental) object.
    * Recording the history of roles.
    * Recording events.
    * Recording computations.
    * Rec

Re: Need for Diagnostic Methods/Algorithms to Classify Domain Objects

Peter Ritchie — 2012-04-19T22:34:23

These patterns are how you implement logic within your domain.  If you
don't know what you're implementing, being able to diagnostically look at a
class and classify it as implementing a specific pattern isn't going to
offer much value.  E.g. if you don't know a type is an Aggregate Root, the
fact that some analysis rules can "prove" it's an Aggregate Root doesn't
really help you much.

i.e. these patterns are implemented deterministically, not accidentally.
 If you don't already know what patterns these classes implement,
classifying them as anything in particular is just coincidence.

Now, if we're talking about what it means to implement these patterns like
Aggregate, Aggregate Root, Entity, Value Object, etc. then we're talking
about something different.  And I agree; asking someone about these
things often gets you a different answer depending on who you ask.  Which
isn't a DDD-specific problem.

Rather than re-write the DDD book in an email thread; maybe you can detail
some areas of confusion that you

Need for Diagnostic Methods/Algorithms to Classify Domain Objects

Ali Çevik — 2012-04-19T21:17:18

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:

Re: DDD and Spring Security 3.1

SÅawek — 2012-04-18T19:49:27

IMHO Security is feature of the Application.
In other words: imagine having domain (modeled with Building Blocks) and on the top of this You can build: a) secured app b)unsecured app

But, maybe... Your domain is all about security, than its another story:)

btw: take a look at our Spring (also web mvc) sample: http://code.google.com/p/ddd-cqrs-sample/ - 50 A4 pages in wiki, over 200 classes, BDD (JBehave and Selenium included) and CqRS

general overview: http://prezi.com/hi2dmhfej9zu/ddd-cqrs-sample/ (with clickable links to SVN)


cheers
S³awek Sobótka



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

Re: DDD and Spring Security 3.1

Remy Fannader — 2012-04-18T05:00:29

Here are clear cut criteria to decide between layers:

   - Components with local execution (one for each user) and transient
   life-cycle (end with session).
   - Components with shared execution (simultaneous access by different
   sessions) and transient life-cycle.
   - Components with shared execution and persistent life-cycle (object
   states must be maintained independently of sessions).

http://caminao.wordpress.com/how-to-implement-symbolic-representations/architecture/

Re: DDD and Spring Security 3.1

Jörgen Andersson — 2012-04-18T04:35:01

Hi,

Welcome to the group.

From your description it sounds like a very technical class, hence the
infrastructure layer seems a good choice. However, if it is really using
objects from the business domain, it might be more business oriented and
thereby fits better as an application service.
You don't say anything about what your domain is so I can't say wether
those objects supporting user details should be in the domain or not.
Perhaps they are part of another context? If so, the SS service might be a
natural application service of that domain.

In general, when it comes to layering in DDD-architectures I have come to
favour an "onion-style" rather than the strict "lasagna-style" common in
most architectures. I place the domain in the center, dependent on nothing
and then both application services and infrastructure are part of rthe
surrounding layer, which I often call "integration". It is really an
implementation if the DDD anti-corruption layer. With this style the domain
defines interfaces of the infras