Architects’ Focus Is on the Boundaries and Interfaces
来源:互联网 发布:域名备案到期 编辑:程序博客网 时间:2024/06/05 00:36
Architects’ Focus Is on the Boundaries and Interfaces
Einar Landre
Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, “divide and conquer” has been the mantra for dealing with complex and difficult problems. A more familiar term with the same intent is separation of concern. From separation of concern we get encapsulation, and from encapsulation we get boundaries and interfaces.
From an architect’s point of view, the hard part is to find the natural places to locate boundaries and define the appropriate interfaces needed to build a working system. This is especially difficult in large enterprise systems, often characterized by few natural boundaries and intertangled domains. In this situation, old wisdom such as “Minimize coupling, maximize cohesion” and “Do not slice through regions where high rates of information exchange are required” provide some guidance, but they say nothing about how to communicate the problems and potential solutions to stakeholders in a easy way.
Here the concept of bounded contexts and context mapping, as described by Eric Evans in his book Domain-Driven Design (Addison-Wesley Professional), comes to the rescue. A bounded context is an area where a model or concept is uniquely defined, and we represent it as a cloud or bubble with a descriptive name that defines its role and responsibility in the domain at hand. As an example, a shipping system might include contexts such as Cargo Operation, Cargo Scheduling, and Harbor Movement. In other domains, other names will be appropriate.
With the bounded contexts identified and drawn up on the whiteboard, it’s time to start to draw the relationships between the contexts. These relationships might address organizational, functional, or technical dependencies. The result from this exercise is a context map, a collection of bounded contexts and the interfaces between them.
Such a context map provides architects with a powerful tool that allows them to focus on what belongs together and what should be kept apart, enabling them to divide and conquer wisely in a communicative way. The technique can easily be used to document and analyze the as-is situation, and from there guide redesign toward a better system characterized by low coupling, high cohesion, and well-defined interfaces.
Einar Landre
Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, “divide and conquer” has been the mantra for dealing with complex and difficult problems. A more familiar term with the same intent is separation of concern. From separation of concern we get encapsulation, and from encapsulation we get boundaries and interfaces.
From an architect’s point of view, the hard part is to find the natural places to locate boundaries and define the appropriate interfaces needed to build a working system. This is especially difficult in large enterprise systems, often characterized by few natural boundaries and intertangled domains. In this situation, old wisdom such as “Minimize coupling, maximize cohesion” and “Do not slice through regions where high rates of information exchange are required” provide some guidance, but they say nothing about how to communicate the problems and potential solutions to stakeholders in a easy way.
Here the concept of bounded contexts and context mapping, as described by Eric Evans in his book Domain-Driven Design (Addison-Wesley Professional), comes to the rescue. A bounded context is an area where a model or concept is uniquely defined, and we represent it as a cloud or bubble with a descriptive name that defines its role and responsibility in the domain at hand. As an example, a shipping system might include contexts such as Cargo Operation, Cargo Scheduling, and Harbor Movement. In other domains, other names will be appropriate.
With the bounded contexts identified and drawn up on the whiteboard, it’s time to start to draw the relationships between the contexts. These relationships might address organizational, functional, or technical dependencies. The result from this exercise is a context map, a collection of bounded contexts and the interfaces between them.
Such a context map provides architects with a powerful tool that allows them to focus on what belongs together and what should be kept apart, enabling them to divide and conquer wisely in a communicative way. The technique can easily be used to document and analyze the as-is situation, and from there guide redesign toward a better system characterized by low coupling, high cohesion, and well-defined interfaces.
- Architects’ Focus Is on the Boundaries and Interfaces
- Architects’ Focus Is on the Boundaries and Interfaces
- Focus on the target
- Auto focus on the first textbox and tab on the entery key
- work on job and focus on business
- Augmented Reality: New Interfaces on the Way?
- Focus on Application Support and Maintenance
- [INS-41107]eth0 selected for one or more of the public or private interfaces is not on a shared subn
- The Closeable, Flushable, Readable, and Appendable interfaces
- escarpin louboutin pas cher Wuhan public focus on the destruction of 900 kg of drugs and the city's
- Architects Must Be Hands On
- Word Boundaries and Slack Byte
- Boundaries
- Is the server running on host “localhost” (::1) and accepting TCP/IP connections on port 5432?
- The State of Visual Analytics Views on what visual analytics is and where it is going
- What exactly is copy-on-modify semantics in R, and where is the canonical source?
- Love is in the air and the flowers are on their way
- Warning:The `android.dexOptions.incremental` property is deprecated and it has no effect on the buil
- windows2003下MySql数据的重装系统后恢复
- js获取地址栏参数
- 我的第一份工作
- jquery从零学起
- ORACLE纯SQL实现多行合并一行
- Architects’ Focus Is on the Boundaries and Interfaces
- 挂科
- [WARN]Warning: Multiple build commands for output file /
- 【Android】ListView滑动时首字母提示效果
- linux上erlang编译安装手记
- js的日期格式化函数
- iOS面试重点问题
- Linux 信号说明列表
- 使用linux一个月,一直在傻逼行走