DOM and Database

Hello,
I am very new to DDD...
Many examples I have seen so far more or less reconstruct their Domain Object Model (DOM) on every service
call. In the following "persistence" could be Hibernate or even just jdbc
So the flow is 
1) service call A 
2) "persistence" goes to DB and constructs the needed DOM 
3) DOM returns result to service A
4) service call B
5) "persistance"  goes to DB and constructs again the needed DOM 
6) DOM returns result to service B
...
But I would much prefer the following: 
1) At the beginning of my application I construct a DOM which can answer all server requests.
2) service call A
3) DOM returns result to service A
4)service call B
5) DOM returns result to service B
....
Since in most of the examples I `ve seen the first approach seems to be mostly used....
Is there something wrong with using
the second approach together with a persistence framework? Or is it just not practical for a enterprise application?

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

IDs in the domain

Hello everyone,

I'm reading my way through Vaughn Vernon's "Implementing DDD" and I'm currently half-way through. I like
the general approach, however, there's a thing that bothers me: the code is teeming with IDs. TenantId,
userId, whateverId.

IDs such as these don't have a place in the ubiquitous language of a bounded context and I really don't want to
deal with them in code implementing the domain logic.

In my view, using IDs there amounts to an ill-encapsulated, manually-managed de/serialization
strategy. The IDs are only stand-ins for proper objects, so why not handle the conversion at the boundary
and then work with domain objects throughout the domain code?

Put slightly differently, when I hold an entity, there's no need for a conceptually separate ID. An entity
is identical only to itself and as such is its own identity. IDs only come into it if an entity needs a
shortcut to represent it outside of its original context.

So, are there common opinions or even a consensus on IDs among DDD practitioners? Is the approach in IDDD representative?

Michael

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

Created DDD Exampe - Feedback?

Hi <at> all

I really like the idea of domain-driven design. Based on a project I am working on at the moment I created a
small example about what can happen to application architecture if strategical and tactical patterns
are applied to the problem space.

This example can be seen here:

http://www.mirkosertic.de/doku.php/architecturedesign/dddexample

It is far from being perfect, but it should show up a direction about how to find subdomains, bounded
contexts, aggregates, context integration and application architecture.

Any feedback is very welcome, so stay tuned and happy DDDing

Regards
Mirko

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

Succeeding with DDD - Documentation

A value object *must be* immutable?

Iterative development and tests: how to aim at moving targets.

Test driven development can be seen as a mirror image of model driven development, a somewhat logical
consequence considering the limited role of models in agile approaches.
The downside is that without fully defined objectives, there is a question mark on the kind of reference
against which programs are to be tested; likewise, the question is how results are to be managed across
iteration cycles, especially if changing requirements are to be taken into account.
Remy.
http://caminao.wordpress.com/2013/04/24/tdd/

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

AR Create instance for AR

Hi guys

My situation is following: I have a AR named as Task, it's has a method DispatchFor(Area area). The problem
is that when this method is called, it change object state and create new Task object to area sent with parameter.

What do you think? Where is missing? I keep it? or take this logic to a Domain Service?

public class Task : AggregateRoot
{
	public void State State {get; protected set;}
	public void TaskType Type {get; protected set;}
	public void Area area { get; protected set;}
	
	public Task(TaskType type, Area area)
	{
		Type = type;
		Area = area;
		State = State.Pending;
	}
	
	public Task DispatchFor(Area area)
	{
		State = State.Performed;

		if (area.IsDirectorShip)
			return new Task(TaskType.Analyze, area);

		if (area.IsManagement)
			return new Task(TaskType.Providence, area);

		return new Task(TaskType.File, area);
	}
}

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

Integrating BCs - in real life

Hi all,

If one application service in one bounded context (BC) needs to access the domain models for several BCs,
how will this look like in the runtime environment?

I see two alternatives:

1. The various BCs are hosted/deployed separately. In this case, operations on "remote" domain models
could be accessed through (web) services or similar. A side effect is that transactions cannot span such
remote operations, and that domain operations must be wrapped in a service layer. Web service hell?

2. The various referred domain models are deployed with the BC that refers to them. This means that calls are
in-process. BUT this also means that the "host " BC must hold connection strings and optionally other
config for all the domain models (repositories) it uses. Config hell?

Both options seem to have large drawbacks to me. Is there something I have missed?

Atle

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

Melbourne DDD meetup

One-to-one ARs and an identity crisis

Value Objects and Composite Design Pattern

Hi, everybody

I'd like to read opinions about this model:

'Survey' HAS A 'SurveyElement', where this one is an implementation of the Composite design pattern.
So 'Question' (the leaf) and 'Block' (the composite) implement 'SurveyElement'.

I'm treating 'SurveyElement' as a value object, since everytime I edit the survey, a new structure (tree)
is created (the 'root' block and all its blocks, questions, blocks inside blocks, so on).
In other words, I don't care about life cycle of the structure of survey elements.

But, as value object, 'Block' is equal another 'Block' only when the whole tree is equal the tree of the other
block. So I must implement 'Equals' considering all this path down the tree (and this may be a slow process).

What do you think about that design? Is it 'correct' designing a value object compounded of a list of value objects?

I'd appreciate your suggestions and comments.
Thanks.

ps.: I'm posting this to Domain-Driven Design groups on Yahoo and Google Groups. So please, disconsider
one of theirs.

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