The problem with many software solution decisions is more around politics and where higher management reckons IT fits in. Or I have to develop a DDD ERP in order to increase revenue ? Will there be space for DDD in regular IT systems for bigger clients ? Sometimes fear and tend to choose a worse "well-known" solution. Of the clients needs, many companies seem to be driven by trends and More technically designed and thus more directed to the business specifics Popular among mid-size companies what make me think if it really worth toĬontinue to develop software from scratch.īriefly speaking, my personal impression is that although DDD software is
Standard business processes are there and there is a "experienced vendor"īehind the product. However I have noticed that large corporations which are the biggest ITĬonsumers preffer to have a all-packed solution such as an ERP.Įven if ERPs have disadvantages such as many business re-engineering toĪdequate to the ERP standard, they are preffered since all I can clearly see theīenefits for the clients in terms of competitive advantage specially in the Other factors, a lot of thinking in terms of correct business representationĭesign patterns such as layers, factories, etc. (BTW: The real essence is not RESTful or not.I like very much the DDD way of producing software which involves, among We have very interesting performance results (over 50.000 aggregates pr second) from a Proof of Concept on Continual Aggregate Hub running it in a grid. The Event logger is also an important aspect of it so that re-running event is possible. The Domain Event Publisher (page 37) is the Process-state and handling of the CDH, and it is relaxed so that subscribing Modules may consume at a pace they wish. Maybe lifecycle is not a good word, but it chosen to illustrate what drives behavior on the domain objects, between and within, these loosely coupled systems (they have separate bounded contexts). I especially like the Domain Event (page 19 and 34), it is the implementation of what I have called the ´Lifecyle´. In in the migrate to the cloud I am talking about ´ Cooperating federated systems´ and this is exactly what I observe Vernon is talking about in his presentation. The Continual Aggregate Hub and restaurant is really a macro description of how such domain systems may cooperate in a pipeline, and how they can share a document (this is how we store Aggregates) storage. It actually fils a gap very nicely as to how our target architecture may be implemented, and more importanlty why it should behave as as described. It is very clear and educational and should be made basic training at our site. I find this talk by Vaughn Vernon very encouraging and it fits nicely into what we are trying to achieve.
0 kommentar(er)
