Re: separating global and country-specific logics in large DDD application

Hi,

The key conceptual tool is the "bounded context".

You probably have a shared kernel containing concepts like Currency, Money,
Time (UTC! ;-) and common identifiers (ISIN, MIC and so on...).

Then you should isolate different bounded contexts according to the
different business rule sets. To take the right direction, I've explored
with the domain experts two of the more different regulations, to identify
common concepts and rules, and after that, I talked with experts from the
other 3 country to confirm/dispose the abstractions previously defined.

In our business, similarities were few but really stable, so we have built
one single shared kernel holding them all, and one different domain model
for each country. Indeed we realized that the "ubiquitous language" was
different in the different countries (outside the common and very abstract
concepts in the kernel).

This lead to different applications for each country (because of the
different domain models beyond the kernel), thus it can look expensive, but
is very flexible (as each country's regulations evolve differently) and
cheaper in the long run.

On the other hand the shared kernel has had almost no evolution.

Note however that with different projects that share part of the domain
model (the shared kernel, in my case), you have to set up strict policy for
versioning and to track dependencies: if you can't, it's cheaper to build a
completely different application for each country with a shared nothing
approach, using cut&paste when appropriate.


Some more little suggestions, from my previous experience: keep attention
to Exceptions from the domain experts (1) since they help to identify
subtle differencies and use immutable value objects widely (2) since they
are easier (and thus cheaper) to localize.


Hope this helps.


Giacomo
[1]
epic.tesio.it/2013/03/04/exceptions-are-terms-ot-the-ubiquitous-language.html
[2]
http://epic.tesio.it/doc/manual/epic-prelude.html#about_interpreting_values

On Mon, Mar 11, 2013 at 4:38 PM, jlamkw <[email protected]> wrote:

> **
>
>
> Hi everyone
>
> I'm using DDD for a global financial application (ASP.Net front-end WCF
> backend, NHibernate) that will be deployed to multiple countries (each
> having a completely separate installation and user base). All countries
> share some common logics and data (e.g. Account). But each country also
> requires some country-specific logics (e.g. extra values in enums, new
> properties, different logics for UK-only account types).
>
> Any suggestions on how should I go about structuring my DDD stack
> (entities, domain services and repositories)? I certainly don't want all
> country-specific logics to end up becoming one big ball of mud so I need a
> way of keeping the codes for each country separate.
>
> I've considered various techniques e.g. inheritance, composition, partial
> classes, complete fork...but none seems to stand out.
>
> Are there any DDD techniques/patterns for tackling this specific kind of
> complexity? Those DDD examples I've read in books seem to assume universal
> / country-agnostic system.
>
> Regards,
> Joseph
>
>  
>