• 松耦合就是降低系统部件和部件之间的耦合性,也就是降低部件的依赖性,使得部件之间相对独立,这样对于日后系统的维护及扩展都是很有好处的,然而在J2EE领域,为实现松耦合出现的技术可谓让人眼花缭乱,这些技术的出现究竟是使问题简单化了还是复杂化了呢？ 首先是数据工厂技术,这种技术使用到了传
  • 微服务避免了代码重用，其理念是：宁可代码重复，也要彻底避免耦合，因为重用意味着耦合，微服务架构是完全分离的。进化的架构！所以，DRY原则并不适用微服务。Microservices eschew code reuse, adopting the philosophy of prefer icon
  • http://www.jdon.com/artichect/coupling.htm 松耦合一个反义 icon
  • 这是一篇关于两个DDD模式如何相互矛盾的文章。这两种领域驱动设计模式 -  icon
  • 虽然我们使用SpringBoot实现微服务，但是在一个微服务中还是有可能塞入很多模块；同时从单体向微服务过程中，只有先将单体切分成模块以后，这些模块之间的依赖越来越少，这些模块才能逐个独立成微服务。 有没有一个有效手段在当前单体架构下发现模块之间的依赖关系 icon
  • 编程是从浪费生命中学到的可怕教训，编写易于删除但不易扩展的代码。 “每一行代码都是在没有理由的情况下编写的，有自己的弱点，并且偶然间会被删除” Jean-Paul Sartre的ANSI C编程。 icon
  • 从构建大规模多区域分布式系统中汲取的经验教训！在设计系统时，软件架构师通常需要选择各种依赖关系 - 基础架构，身份验证，存储，当我第一次开始在IBM担任软件架构职责时，我倾向于选择完成工作的依赖项，但很快我就学会了这一课：做一个极简主义者。只有在绝对需要时才引入新的依赖关系。 icon
  • 松耦合很有意思，越学越带劲啊。只是觉得这条路真的还是蛮长的。 感觉松耦合会损失系统的性能，损失系统的可读性（增加了复杂性），但是也能增加系统的灵活性，扩展性。这是不是一种取舍？我说得对么？ icon
  • 今天看POJOs IN ACTION书中有类似这样一段话“传统的J2EE应用程序使用JNDI作为一个组件访问另外一个组件的依据，比如JNDI访问EJB组件，JNDI访问Datasource获取服务器上的数据库连接池中的连接，但是JNDI的弱点在于它把应用程序和应用服务器耦合在一起，难于测试和维护。而 icon
  • 有模式的解藕,必然在其它地方有藕合,只不过把这条链子加长了, 以前只要两个类便可以实现的东西现在要三个或都更多?这样做有多少必要? icon
  • 面向接口编程是说的比较多的了。 任何有独立意义的class的都要先定义接口，再写实现类吗？让这些class都隐藏在interface后面？都通过interface交互？ 还是只对有多种实现，或者潜在的会有多种实现 icon
  • 在设计模式中是怎样达到弱耦合的？请各路高人解答一下吧，谢谢了！ icon
  • 减小耦合到底是为了什么？比如说有两块代码A和B。我修改了A代码，如果A和B之间的耦合小的话，那么B代码就不会因此受到牵连，也必须修改。怎样做到这一点呢？可以是继承，A和B都继承自一个接口；也可以是组合，A中有一个B的抽象基类的字段。可是，如果接口不够用了怎么办 icon
  • 问题如何支持低依赖性，低变化影响并增加重用？ 解决方案分配责任以使耦合保持低水平。 关于低耦合的要点 “ icon