The client doesnt need to know whether DDD is used or any other Model is used to Implement service. DDD is just a Domain Model.ĭDD just sits inside the Business logic layer of SOA. From what i understand SOA is a Distributed Application Architecture.
Using the messaging features of a DBMS, like Sql Server Service Broker, is an entirely different matter and does fall under the "shared infrastructure" you mentioned. Regardless of SOA, I would not use a data source as a bounary between apps. Backdooring them through the database does not seem to fit that definition. Whose stored procs are those? Can the other application change them, or add constraints, triggers, etc? What if they do and it breaks your app?Ĭommunicating, in my book, means letting the listening party decide what to do with the information you send them. When two "applications" communicate, although I'd hardly call it that, through a shared data source (what's been called a database), then the boundaries where one application stops and the other starts gets blurred. There's a difference between sharing infrastructure like a DBMS, or physical database server, and sharing a data source. Often they also understand that each of those applications' implementations may be distributed - with parts of the application communicating with each other through a method of integration - file sharing, shared database, remote method invocation or messaging.ĭoes service orientation in the real world really make database or other shared infrastructure boundaries any clearer? Most basically understand the boundaries of their payroll, ordering and CRM applications. But 'application' is probably one term that most people can identify with reasonably easily. Your point about bluring boundaries is an important one IMHO, and certainly 'service' and 'component' are terms that are overloaded in use and understanding. On the question of orthogonality of DDD and a Service, I would suggest that just because you can use DDD, RAD or scripting to implement a Service, doesn't make them 'orthogonal'. So, whose database is it?Īnyway, good to hear your thoughts on the subject.
For example, databases are often considered to be inside a distributed application, however they are also often used by other applications as well. Personally, I object to the term "distributed application" in that it blurs boundaries that are important. The only difference between orthogonal and "totally unrelated", in my opinion, is that orthogonal "things" have an intersection point - you yourself said it DDD can be used to implement a service.Īs to your point about "applications", I'd have to say that seeing as the terms "service" and "component" are ill defined, "application" shouldn't be much different.
0 kommentar(er)
