Comments on: Domain Driven in the financial world http://www.the-arm.com/2008/04/domain-driven-in-the-financial-world/ A weblog about Methodologies for Development Mon, 14 Jun 2010 09:49:20 +0000 hourly 1 By:   Domain Driven in the financial world (II) by toniBlog http://www.the-arm.com/2008/04/domain-driven-in-the-financial-world/comment-page-1/#comment-10088   Domain Driven in the financial world (II) by toniBlog Tue, 17 Jun 2008 03:27:01 +0000 http://blog.java2me.org/2008/04/19/domain-driven-in-the-financial-world/#comment-10088 [...] was right on his comment on my previous post about DDD in the financial world: we had a new requirement from the client: [...] [...] was right on his comment on my previous post about DDD in the financial world: we had a new requirement from the client: [...]

]]> By: toni http://www.the-arm.com/2008/04/domain-driven-in-the-financial-world/comment-page-1/#comment-9647 toni Sat, 17 May 2008 23:48:32 +0000 http://blog.java2me.org/2008/04/19/domain-driven-in-the-financial-world/#comment-9647 Hi Alberto, I totally agree with your sentence "approaching complex domains with learner’s eyes is normally a “plus” because could help followers to help learning a possibly simpler domain model". I think that here is were we are great at, the design we are implementing is much simpler. If you're very strong technically or in the domain it's much difficult to let emerge abstractions, that's were an agile developer can dramatically improve the quality of a system. On the other hand without a strong and continuous efficient communication with the domain experts the solution will risk to do not converge the expected one! Hi Alberto, I totally agree with your sentence “approaching complex domains with learner’s eyes is normally a “plus” because could help followers to help learning a possibly simpler domain model”.
I think that here is were we are great at, the design we are implementing is much simpler.
If you’re very strong technically or in the domain it’s much difficult to let emerge abstractions, that’s were an agile developer can dramatically improve the quality of a system.
On the other hand without a strong and continuous efficient communication with the domain experts the solution will risk to do not converge the expected one!

]]> By: toni http://www.the-arm.com/2008/04/domain-driven-in-the-financial-world/comment-page-1/#comment-9645 toni Sat, 17 May 2008 23:40:17 +0000 http://blog.java2me.org/2008/04/19/domain-driven-in-the-financial-world/#comment-9645 <p>Hey Josh thanks for youe comment,<br /> I remember a nice conversation had with <a href="http://dannorth.net/" rel="nofollow">Dan North</a>, it's also everything about context. So, the DSL with strange numbers is perfect in the context of the IT Department, where QAs, FiX experts are happy with it. On the other hand, in the code, for new team on-boarding, it's easier to have speaking names and that's what we have in our tests.<br /> On other levels / departments of the organization our app should just work, no need to understand how and why and it's should be completely transparent. I'm sure that a trader ignores what's there, behind the scenes :-)</p> Hey Josh thanks for youe comment,
I remember a nice conversation had with Dan North, it’s also everything about context. So, the DSL with strange numbers is perfect in the context of the IT Department, where QAs, FiX experts are happy with it. On the other hand, in the code, for new team on-boarding, it’s easier to have speaking names and that’s what we have in our tests.
On other levels / departments of the organization our app should just work, no need to understand how and why and it’s should be completely transparent. I’m sure that a trader ignores what’s there, behind the scenes :-)

]]> By: Alberto Brandolini http://www.the-arm.com/2008/04/domain-driven-in-the-financial-world/comment-page-1/#comment-9572 Alberto Brandolini Mon, 12 May 2008 09:08:35 +0000 http://blog.java2me.org/2008/04/19/domain-driven-in-the-financial-world/#comment-9572 Hi Antonio, This is a puzzling experience. Long lasting systems tend to become "the domain" especially if you have to deal with the very people that created the system as Domain Expert. Unfortunately they tend to mix up problems and 20 years old solution in the same pot, so you can't exactly figure out what the original problem was and why the solution has been designed this way. After 20 years use, the solution IS definitely part of the domain. I believe that approaching complex domains with learner's eyes is normally a "plus" because could help followers to help learning a possibly simpler domain model. On the other hand, every IT people has to face the command-line-power-user-myth: the creatures who is so proficient with the old system that needs every new system to completely mimic the old one. I honestly doubt that people that can't compensate a small change in UI are "incredibly efficient" but I do normally avoid to question that. What I discovered, is that new job market dynamics are making easy-to-learn systems more appealing in companies with a higher turnover. And learning code 115 or XB3 is a waste of time. The point is that your application ecosystem will be different from the application development ecosystem. What Eric Evans stresses is that you have to put a lot of effort to make the two ecosystems overlap, and maybe talk the same language. This task is not easy at all, and human factor is success factor number one, 'cause your job must not be seen like a treat but like an opportunity instead... Ciao Alberto Hi Antonio,

This is a puzzling experience. Long lasting systems tend to become “the domain” especially if you have to deal with the very people that created the system as Domain Expert.

Unfortunately they tend to mix up problems and 20 years old solution in the same pot, so you can’t exactly figure out what the original problem was and why the solution has been designed this way. After 20 years use, the solution IS definitely part of the domain.
I believe that approaching complex domains with learner’s eyes is normally a “plus” because could help followers to help learning a possibly simpler domain model. On the other hand, every IT people has to face the command-line-power-user-myth: the creatures who is so proficient with the old system that needs every new system to completely mimic the old one. I honestly doubt that people that can’t compensate a small change in UI are “incredibly efficient” but I do normally avoid to question that. What I discovered, is that new job market dynamics are making easy-to-learn systems more appealing in companies with a higher turnover. And learning code 115 or XB3 is a waste of time.

The point is that your application ecosystem will be different from the application development ecosystem. What Eric Evans stresses is that you have to put a lot of effort to make the two ecosystems overlap, and maybe talk the same language. This task is not easy at all, and human factor is success factor number one, ’cause your job must not be seen like a treat but like an opportunity instead…

Ciao

Alberto

]]>