gmane.comp.programming.domain-driven-design

Re: Re: ddd and deployment challenges - London, Dec 16

Gojko Adzic — 2008-12-04T16:00:12

it should be. skills matter record these talks, although the sound is often not as good as i'd like. In any case, it takes them about two weeks to publish talks online, so expect a video to become available somewhere around Christmas. -- gojko adzic http://gojko.net Colin Jack wrote: ------------------------------------

Re: ddd and deployment challenges - London, Dec 16

Colin Jack — 2008-12-04T15:52:22

Hi Gojko, Will the talk be recorded for those of us who cannot make it? Ta, Colin ------------------------------------

ddd and deployment challenges - London, Dec 16

Gojko Adzic — 2008-12-04T15:42:04

Hi, I'll be doing a talk on DDD and deployment challenges on the 16th in London. In the talk, I'll explore strategies, challenges and common pitfalls of using Domain driven design for multi-tier distributed applications. The event is free to attend, but up-front registration is required (and I suggest you register straight away if this sounds interesting). For more information and to register, see: http://skillsmatter.com/event/design-architecture/ddd-and-deployment-challenges -- gojko adzic http://gojko.net ------------------------------------

Re: Re: Repository responsibilities

Jonathan Harley — 2008-12-04T05:12:45

No, they can not be reconciled. Dispose of this "friend" immediately! Seriously though, in my old incarnation as a database, data-driven application developer, I would have taken your friend's view. Since then, I have gone through an application development epiphany and now view the database as a storage mechanism for persistent objects. In fact, I challenge my development teams to work on a solution using simple persistence, starting with memory-based and moving to simple storage like CSV or XML. This helps them work on the object relationships and getting the repositories right. One of the last things we do is to introduce an OR mapper like iBATIS.NET or NHibernate, but by then the interfaces are clear and the substitution of the storage method is easy. Not to put too fine a point on it: There is no data without the application Whether the application is a set of queries or a sophisticated Web 2.0 construction, there is no need to store data without a use for it. Similarly, if the data stays unch

Re: Repository responsibilities

berthooyman — 2008-12-03T21:13:03

I'm slightly scared by what appears to be a fairly common idea, that the DB supports the domain model. I would say the domain model supports your bussiness logic implementation. The data, and the schema, are in many cases much more resistant to change than your application, especially when you have multiple apps working against the same data set. Object-orientation as a whole has done little to maintain a focus on the core business data, and most of us will have had at least a few heated discussions with DBA's. Referring to the database as an infrastrucutre detail will get them at their toes. I work at a client who has only recently allowed JDBC access to their core production databases, for read-only purposes that is; until now you had to go via CICS to get some data in or out. Discussing database schema changes whas and still is not an option, and to insert or update data we still have to go via CICS. Any domain model we do there has to obey the existing data schema. No discussions around that. --- In

Re: Re: Repository responsibilities

Peter Morris — 2008-12-03T20:59:47

Quite easily. As the structure of the domain model changes the DB structure changes to accomodate it. The DB is there to support the domain model, not dictate its structure. Likewise the model is there to control the logic of what should happen to the data rather than merely be a class representation of tables. The fact that the domain is persisted to a DB is simply an implementation detail, you could work without the DB if you could guarantee that your machine would never reset + you had enough memory :-) Pete ==== http://mrpmorris.blogspot.com http://www.capableobjects.com ------------------------------------

RE: Re: Repository responsibilities

Randy Stafford — 2008-12-03T20:57:41

Hi Kent, See this posting: http://tech.groups.yahoo.com/group/domaindrivendesign/message/6103 Cheers, Randy _____ From: kskinner_08 [mailto:kent_skinner< at >hotmail.com] Sent: Wednesday, December 03, 2008 1:05 PM To: domaindrivendesign< at >yahoogroups.com Subject: [domaindrivendesign] Re: Repository responsibilities Thanks to all for your replies. It seems there is agreement that business logic does not belong in repositories at all; that fits with my instinct of what a repository should be. A related question, slightly off-topic; I was enthusiastically discussing DDD with a friend, and his position was that the database was the most important thing since the data often survives the applications built upon it. My position has been to let the domain- model drive the database schema - I see the database as an infrastructure detail. He sees, I think, the domain-model as a temporary "view" of the data which will be scrapped next year. It got me thinking; can these seemingly opposed views

Re: Re: Repository responsibilities

Casey Charlton — 2008-12-03T20:54:59

Despite the data surviving longer than your domain, the database structure is unlikely to, however that is the M in ORMapper. Casey On 3 Dec 2008, at 20:04, "kskinner_08" hotmail.com> wrote:

Re: Repository responsibilities

kskinner_08 — 2008-12-03T20:04:47

Thanks to all for your replies. It seems there is agreement that business logic does not belong in repositories at all; that fits with my instinct of what a repository should be. A related question, slightly off-topic; I was enthusiastically discussing DDD with a friend, and his position was that the database was the most important thing since the data often survives the applications built upon it. My position has been to let the domain- model drive the database schema - I see the database as an infrastructure detail. He sees, I think, the domain-model as a temporary "view" of the data which will be scrapped next year. It got me thinking; can these seemingly opposed views be reconciled? Thanks, Kent --- In domaindrivendesign< at >yahoogroups.com, "Carlos Peix" ...> wrote: domain, but logic. like a good an making etc. service, ------------------------------------

Re: Ubiquity of Language

Colin Jack — 2008-12-02T17:01:33

(customer, "thing", person the AP Yeah thats the best approach I've found, making the domain expert aware of what you are doing and why. Going down that path you can maintain the UL's consistency as far as the core model. ------------------------------------

Re: Re: Generic repository IRepository or concrete repository?

Greg Young — 2008-12-02T16:32:17

I will just point out the obvious that only some of your aggregate roots support this not all of your aggregate roots. Only the ones that are ICRUDRepository support it. As an example you could have say a customer repository that doesn't support it. As such you are not creating a supertype for all of your repositories, just a supertype that simplifies operations with *some* of them which I find to be ok. My point is that I have never have a need for a generic editing interface for all of my aggregate roots (a supertype for all repositories). I have never really had a need in production code to use all of my repositories polymorphically. Cheers, Greg On Mon, Dec 1, 2008 at 10:27 PM, Jørn Wildt fjeldgruppen.dk> wrote:

RE: Re: Ubiquity of Language

Carlos Peix — 2008-12-02T14:10:44

Exactly Pete! Additionally, I didn't hide from the user the fact that the role (customer, supplier) can be attached to the company as necessary or to another "thing", person, for example. Doing this, I can forget about the company or person and start talking about customer in the AR sub domain or supplier in the AP sub domain. That's valuable IMO, and very rewarding. Regards Carlos Peix _____ De: domaindrivendesign< at >yahoogroups.com [mailto:domaindrivendesign< at >yahoogroups.com] En nombre de Peter Morris Enviado el: Martes, 02 de Diciembre de 2008 11:20 a.m. Para: domaindrivendesign< at >yahoogroups.com Asunto: Re: [domaindrivendesign] Re: Ubiquity of Language In the past I have used this pattern (before I knew what it was called). I usually just say to the client "This is a company. Which roles can it perform? Customer, Supplier, anything else?" How I implement the Customer and the Person sharing those roles is my concern :-) Pete ==== http://mrpmorris. blogspot

Re: Re: Ubiquity of Language

Peter Morris — 2008-12-02T13:20:26

In the past I have used this pattern (before I knew what it was called). I usually just say to the client "This is a company. Which roles can it perform? Customer, Supplier, anything else?" How I implement the Customer and the Person sharing those roles is my concern :-) Pete ==== http://mrpmorris.blogspot.com http://www.capableobjects.com ------------------------------------

RE: Re: Ubiquity of Language

Carlos Peix — 2008-12-02T12:30:12

Whether we should user pattern names or not depends on the pattern type. I think Eric say it right, "software patterns" is a broad concept. For example, "analysis patterns" as defined in the "old" Fowler's book are far more understandable for users than "design patterns" as defined in the GOF book. Regarding the party/role pattern, I prefer to name it actor/role and, better yet, doesn't have to use those names. Just Company/seller or Buyer. Regards Carlos Peix _____ De: domaindrivendesign< at >yahoogroups.com [mailto:domaindrivendesign< at >yahoogroups.com] En nombre de Colin Jack Enviado el: Martes, 02 de Diciembre de 2008 09:47 a.m. Para: domaindrivendesign< at >yahoogroups.com Asunto: [domaindrivendesign] Re: Ubiquity of Language Oh definitely, that's a very different issue and totally agree I wouldn't use those terms with domain experts or users and wouldn't even discuss those parts of the solution.

Re: Ubiquity of Language

Colin Jack — 2008-12-02T11:47:04

Oh definitely, that's a very different issue and totally agree I wouldn't use those terms with domain experts or users and wouldn't even discuss those parts of the solution. ------------------------------------

Re: Generic repository IRepository or concrete repository?

Colin Jack — 2008-12-02T08:45:11

You are correct we could use delegates, and have used that approach elsewhere, but I prefer the interface based approach. ------------------------------------

Re: Re: Ubiquity of Language

Peter Morris — 2008-12-02T08:33:37

Snap but are you just meaning that C# as a language naturally leads you away from a UL centric approach, or were you just meaning that the code is not written in plain English? < When you discuss the business model you use common jargon. Customer, Delivery, Return, etc. For example, on a system I wrote the customer calls sales items "Courier" because "in the old days they used to phone us up, order their items, and we'd send them out via courier for delivery". However, when it comes to writing code you are implementing the model. You can still use verbs/nouns from the shared jargon you established with the customer but that is *what* you are implementing, when you start writing in C# it is *how* you implement it. You don't need to discuss technical terms such as Visitor patterns and remote facades, those are implementation details, the "black box" part of the application. Pete ==== http://mrpmorris.blogspot.com http://www.capableobjects.com ------------------------------------

Re: Re: Ubiquity of Language

Casey Charlton — 2008-12-02T08:15:18

If the domain experts say "Party" and "Role" then by all means it should be in the UL. If they say "User" and "Permissions" then should you impose Party/Role in the UL just because the pattern you use to implement their User and Permissions relationships is actually Party/Role ? A recent example where I got it wrong (sort of) ... the system had Reports, Monitors, and Quarterlies ... it happens that these were 90% similar and therefor they all inherited Document. So I assumed whenever I referred to Document, the users and domain experts would understand this (they did sort of use the term Document, I hadn't made it up totally). Suffice to say they didn't, and didn't understand that a Monitor *was* a Document - so this always caused friction in conversations. It would have been smarter to forget that Document existed as far as the domain experts were concerned, it was an implementation detail they didn't need to know - it would have made no difference to them at all to remove it, other than making it slightly

Re: Generic repository IRepository or concrete repository?

Jørn Wildt — 2008-12-02T06:27:59

Well, it's not a bussiness requirement. It's a technical shortcut. In our case we have N similar screens for N different entity types which you can add/edit/delete/browse through a standard UI. Instead of making N implementations of those windows, we rely instead on one generic UI, one generic UI-controller, and one ICRUDRepository interface for the controller. We could of course have used a more granular interface like IDelete, IAdd etc. In a perfect world I suppose we should build individual UI- controllers for each repository/entity type. But in this case I find the benefits more attractive than being perfect. Is it good practice? Maybe not, but it solves some practical problems without adding any extra dependencies and we still have a clear separation between UI, Domain, and Data Access. You are most welcome to disagree with me :-) /Jørn --- In domaindrivendesign< at >yahoogroups.com, "Greg Young" ...> wrote: IDelete test any in any other that ------------------

Re: Re: Generic repository IRepository or concrete repository?

Greg Young — 2008-12-01T23:58:20

I have never had a use for a generic interface to a repository in my domain such as IRepository based on a business requirement. I don't have "generic code" that can just start grabbing objects through my repositories and deleting them. I might have some small use for a more granular one such as IDelete but that would only be to simplify a few tests as opposed to production behaviors. To be honest I gain very little by even introducing the interface as there are other ways I can write the test of the single methods (delegates). Why introduce IDelete with a method Delete(T t) when I can just define that as a delegate for my generic test? The introduction of any of these interfaces seems like a real stretch to me unless you are in a situation with much more well defined interfaces (I have shown before a way to model a domain that only had a FetchById method on any repository as an example) Cheers, Greg On Mon, Dec 1, 2008 at 1:50 PM, Colin Jack hotmail.com> wrote:

Re: Generic repository IRepository or concrete repository?

Colin Jack — 2008-12-01T21:52:29

I'd just design more granular interfaces, I really dislike the idea of the methods throwing exceptions but its easy to avoid if you just put in a little effort to abstract (e.g. ICanUpdate and ICanDelete, see I've taken you're naming scheme now :)). ------------------------------------